Date: Mon, 1 Jun 2009 17:30:28 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Bruce Simpson <bms@freebsd.org> Cc: Vlad Galu <dudu@dudu.ro>, freebsd-stable@freebsd.org, Jilles Tjoelker <jilles@stack.nl> Subject: Re: Unnamed POSIX shared semaphores Message-ID: <Pine.GSO.4.64.0906011722160.3990@sea.ntplx.net> 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 Mon, 1 Jun 2009, 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. Process-shared semaphores, mutexes, etc, will never work until their public types are structs, not pointers to structs (i.e. allocated by our library functions). The intrinsic *kernel* semaphore functions (ksem) supposedly do support process-shared semantics, but our POSIX functions' use of them cannot be shared across processes. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0906011722160.3990>