[Xcb] [libpthread-stubs] fix semaphore signal safety

[Jamey Sharp]

On Sat, Sep 26, 2009 at 9:09 AM, Samuel Thibault
<samuel.thibault at ens-lyon.org> wrote:
> Jamey Sharp, le Sat 26 Sep 2009 08:59:14 -0700, a écrit :
>> Still, it seems to me that if somebody expects the semaphore functions
>> to actually do something, they should link with pthread.
>
> As the name suggests, semaphores are not so much related with pthreads,
> the sem_* functions were even probably introduced before pthreads.
> It happens that on Linux and a few others OSes it's implemented in
> libpthread, but there is no real reason for that, particularly since
> they can even be inter-processes and still not have anything to do with
> threads.

Which naturally doesn't work in this stub implementation, since
inter-process semaphores need platform support. I was glad to see you
included the appropriate ENOSYS returns in those cases.

I should have said it differently. If somebody expects the semaphore
functions to do something, they should link with the appropriate
platform implementation of those functions, whether that's in pthreads
or elsewhere. We shouldn't be trying to semi-portably duplicate that
functionality in pthread-stubs. Please help me understand why you want
this: I'm just not seeing it.

An alternative question: If the semaphore functions aren't related to
pthreads, why are we adding them to pthread-stubs?

Jamey

p.s. I just spent 30 seconds imagining a POSIX-portable
filesystem-based implementation of inter-process semaphores. It was
frightening.