This is the mail archive of the
mailing list for the Cygwin project.
Re: cygwin stable and cvs snapshot - fork() bug
On Nov 5 09:49, Lev Bishop wrote:
> It indeed seems this is behaviour not described in SuSv3. But several
> unices support (some variant of) this behaviour. At least linux,
> freebsd, hp-ux, solaris 10 mention it in their man pages, and openbsd
> and netbsd seem to implement it that way even though they don't
> describe it in the man pages.
Yeah, we're using the FreeBSD code so the behaviour is already as
in Linux, as I mentioned in my previous mail.
> A further linux extension: In addition to all the above, Linux goes
> even further and still allows you to attach the segment even after
> marking it for deletion.
> Freebsd (since version 5.2) has a sysctl kern.ipc.shm_allow_removed
> which seems to allow you to force the linux behaviour on this issue.
> Openbsd automatically does it (only) when running linux binaries via
Since we're using FreeBSD code, there's a variable shm_allow_removed in
the code already which allows this behaviour. There's just no way right
now to set it. It's always zero. It would be quite easy to add a
cygserver.conf setting for this, though.
> If you do implement the behaviour of not destroying the segment until
> shm_nattach==0, you'll want to make sure that the shared memory key
> can be reused immediately after the old segment has been IPC_RMIDed,
> even though the old mapping may still be around. The other OS's which
> implement it seem to do this by having shmctl(IPC_RMID) change the key
> of the segment to be IPC_PRIVATE.
Since we're using FreeBSD code...
> Don't you just love standards....
The best thing with standards is that we have so many of them.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html