Re: What if process crashes while holding a locked semaphore?
Re: What if process crashes while holding a locked semaphore?
- Subject: Re: What if process crashes while holding a locked semaphore?
- From: Terry Lambert <email@hidden>
- Date: Wed, 1 Apr 2009 16:59:06 -0700
On Apr 1, 2009, at 12:31 PM, David Gatwood wrote:
On Mar 31, 2009, Terry Lambert wrote:
On Mar 31, 2009, at 8:21 PM, Jerry Krinock wrote:
After studying Terry's latest remarks I realize where the real "bug"
is. It seems that Posix semaphores on Mac OS X have limitations,
are not supported and not recommended. Probably their only use is
to allow porting of linux programs.
So the bug is that man pages for the sem_xxx() methods lack a
statement saying that these functions are depracated and not
recommended for new designs.
Would anyone disagree with this?
They aren't deprecated, we just don't promise that they are fully
POSIX compliant at this time.
Hmm. I just checked and I see nothing in the POSIX spec for
sem_wait/sem_post that
requires such behavior. Maybe there's something elsewhere and I
just missed it---not
sure---but I think Mac OS X may be compliant and correct as-is.
It looks like the only guaranteed cross-platform and safe way to
handle this situation would
be to add a signal handler that calls sem_post(...) and then
_exit(255) if you get a
SIGSEGV or SIGBUS signal.
We don't support unnamed POSIX semaphores, we don't support
sem_getvalue(), and if you try you get a SIGSYS, which if you don't
catch it, you're program exits. We also don't guarantee correct error
semantics for the POSIX named semaphores we do have, since if we can't
run the conformance tests because we don't support unnamed semaphores,
we can't tell if the errors we return are correct or not.
Other than that, yeah, there's a man page. 8-).
For future reference, "supported" in POSIX terms is whether or not
there's a 200112L value for the manifest constant for the subssytem in
<unistd.h>.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden