This is the mail archive of the
mailing list for the Cygwin project.
Re: cygipc-1.11 SHM-patch: fork, handling in ipc-daemon
- From: Michael Haubenwallner <michael dot haubenwallner at salomon dot at>
- 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
- Date: Mon, 21 Jan 2002 09:57:16 +0100
- Subject: Re: cygipc-1.11 SHM-patch: fork, handling in ipc-daemon
- References: <3C482133.E3C673D2@salomon.at> <0a9801c1a079$4dd50e60$0200a8c0@lifelesswks>
Robert Collins wrote:
> ----- Original Message -----
> From: "Michael Haubenwallner" <email@example.com>
> > - 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.
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.
Michael Haubenwallner SALOMON Automation GmbH
Forschung & Entwicklung A-8114 Friesach bei Graz
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html