This is the mail archive of the pthreads-win32@sourceware.org mailing list for the pthreas-win32 project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hello.My apologies - I didn't even see the sem_wait() even though it's right before the sem_destroy(), and regardless, as you say, it should only return EBUSY if someone is waiting, not posting. It's been a while but the code looks like it tries to ensure this. I'll have to look closer when I'm more awake.
The library is working correctly since sem_destroy() is returning the error EBUSY as required and documented at:
http://sourceware.org/pthreads-win32/manual/sem_init.html
This is also in accordance with the Single Unix Specification. If it was hanging your program rather than returning the error then that would be a problem.
The sem_destroy function sets errno to the following error code on error: EBUSY if some threads are currently blocked waiting on the semaphore.
But there's obviously no threads waiting on semaphore, is there?
As above - my mistake.
By the way, in your sample code you don't check the return code from the sem_post(), but the semaphore could already be destroyed at that point.
It couldn't (shouldn't, because actually it does). Because semaphore is destroyed only after sem_wait(), but sem_wait() returns (should return) only after sem_post() succeeds. Did I understood right?
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |