sem_init() fails (when used in a certain way)

Christopher Faylor
Wed Mar 30 20:34:00 GMT 2011

On Wed, Mar 30, 2011 at 01:36:18PM -0600, Eric Blake wrote:
>On 03/30/2011 08:31 AM, Corinna Vinschen wrote:
>> On Mar 30 08:07, Eric Blake wrote:
>>> On 03/30/2011 02:01 AM, Corinna Vinschen wrote:
>>>> Thanks for clarifying.  We just have to keep in mind to return EINVAL
>>>> rather than EFAULT.
>>>> Btw., glibc does not test the validity of the semaphore at all.  If you
>>>> give an invalid sem pointer to the sem functions, it just crashes:
>>> Which is allowed by POSIX.  In fact, my understanding is that older
>>> POSIX used to require that invalid objects be identified, until Ulrich
>>> argued that there are pathological cases (such as reuse of heap that
>>> already contains contents from a prior pointer) that make such detection
>>> practically impossible in any reasonable amount of time, so POSIX was
>>> intentionally relaxed to no longer require detection of invalid objects
>>> (they are just as undefined as any other use of a bad pointer) in order
>>> to cater to glibc.
>> So we could not add myfault handler's *and* remove the is_good_object
>> tests everywhere and we would still be on the safe side of Linux and
>> POSIX, right?  That would perhaps speed up extensive usage of the
>> pthread functions noticably.
>Yes - see the text under
> The RATIONALE is quite clear that error checking is possible (and if
>done, what errno values should be used), but that the implementation is
>free to trade less error checking for faster operation.  The only
>mandatory errors are for things like ENOMEM or EAGAIN when there are not
>enough resources available, and not for EBUSY for re-initializing an
>already-initialized object or EINVAL for destroying an uninitialized
>object.  And the change history under ISSUE 7 lists EINVAL and EBUSY
>being removed as required errors as part of POSIX 2008.
>Of course, removing all handlers means that buggy programs that used to
>get EFAULT and now get segfaults are more likely to blame cygwin, but
>that's not a new problem.

I don't know.  Do we want to make some part of Cygwin faster?  I wouldn't
want to spoil anyone.


More information about the Cygwin-developers mailing list