Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <3C4BD7EC.34D68A52@salomon.at>
Date: Mon, 21 Jan 2002 09:57:16 +0100
From: Michael Haubenwallner <michael DOT haubenwallner AT salomon DOT at>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i686)
X-Accept-Language: de-AT, en
MIME-Version: 1.0
To: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
CC: Charles Wilson <cwilson AT ece DOT gatech DOT edu>, cygwin AT cygwin DOT com
Subject: Re: cygipc-1.11 SHM-patch: fork, handling in ipc-daemon
References: <3C482133 DOT E3C673D2 AT salomon DOT at> <0a9801c1a079$4dd50e60$0200a8c0 AT lifelesswks>
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS perl-11

Robert Collins wrote:
> 
> ===
> ----- Original Message -----
> From: "Michael Haubenwallner" <michael DOT haubenwallner AT salomon DOT at>
> > - It is not clear what happens in following circumstance:
> >   1) the first process creates a shm
> >   2) a second one attaches to it
> >   3) now the second process dies without detaching
> >   4) the first process removes the shm with shmctl(IPC_RMID),
> >      but the ipc-daemon was sleeping and did not remove the
> >      second attachment-entry early enough to have shm_nattch==0,
> >      which must be the case in shmctl() to really remove the shm
> >      by the caller of shmctl(IPC_RMID).
> >
> >   What IMHO surely not should happen is that a shmid with
> >   shm_nattch==0 remains with having the destroy-flag set.
> >   So the ipc-daemon must remove a shm in this state,
> >   including the tmp-file.
> 
> In this case, the daemon should wait on all the processes that are
> attached, so it gets woken up when a process quits. Alternatively, you
> could queue the removal, prevent now attachments, and when the second
> process termination is 'noticed' perform the removal.
> 
> Rob

I forgot to say that the removal _is_ done with this patch by the
daemon when the second process (meaning the last attached process)
terminates, which is the 'alternative' way in your description.

haubi

--
Michael Haubenwallner                       SALOMON Automation GmbH
Forschung & Entwicklung                     A-8114 Friesach bei Graz
mailto:michael DOT haubenwallner AT salomon DOT at     http://www.salomon.at

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/