Date: Tue, 2 Jun 2009 08:42:41 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-stable@freebsd.org Cc: Vlad Galu <dudu@dudu.ro>, Bruce Simpson <bms@freebsd.org>, Jilles Tjoelker <jilles@stack.nl> Subject: Re: Unnamed POSIX shared semaphores Message-ID: <200906020842.42330.jhb@freebsd.org> In-Reply-To: <4A24457C.6060100@FreeBSD.org> References: <ad79ad6b0906010833y20042080td1ebe0d3bfffbdc5@mail.gmail.com> <20090601161903.GA40377@stack.nl> <4A24457C.6060100@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 01 June 2009 5:17:48 pm Bruce Simpson wrote: > Jilles Tjoelker wrote: > > If process-shared semaphores really work, then the above structure is > > not a pathological case. Effectively, sem_t is carved in stone. So > > process-private semaphores should continue to have most of their stuff > > in a separately allocated structure, to preserve flexibility. > > > > There was an inadvertent race in FreeBSD's POSIX semaphores which I > fixed in HEAD and STABLE about 6 weeks before 7.2 was released. > > I believe process-shared POSIX semaphores now work -- the Python > 'multiprocessing' regression test now runs to completion with no errors > on both HEAD and STABLE. The semaphores in recent 7 and 8 are definitely not process-shared (at least not intentionally). They may work across a fork accidentally, but you can't store it in an mmap() region and share it with an arbitrary process. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200906020842.42330.jhb>