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/
