X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Mon, 5 Nov 2007 16:17:26 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: cygwin stable and cvs snapshot - fork() bug
Message-ID: <20071105151726.GA20309@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <C0ED6A2866953E4487135B5DFCFF89A501C048D6 AT hmsx21 DOT pnet DOT ch> <20071029083512 DOT GA4224 AT calimero DOT vinschen DOT de> <C0ED6A2866953E4487135B5DFCFF89A501C04A65 AT hmsx21 DOT pnet DOT ch> <4725D656 DOT 5090303 AT cygwin DOT com> <C0ED6A2866953E4487135B5DFCFF89A501C375CD AT hmsx21 DOT pnet DOT ch> <ba40711f0710311126m6ae84f5ci4e7e481869ed63a7 AT mail DOT gmail DOT com> <20071101095835 DOT GG31224 AT calimero DOT vinschen DOT de> <20071105102147 DOT GI31224 AT calimero DOT vinschen DOT de> <ba40711f0711050443h6733c234o3c2d4a78f410360d AT mail DOT gmail DOT com> <ba40711f0711050649g3276b097yb88ae247b1cfdc29 AT mail DOT gmail DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ba40711f0711050649g3276b097yb88ae247b1cfdc29@mail.gmail.com>
User-Agent: Mutt/1.5.16 (2007-06-09)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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
> compat_linux(8).

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

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/