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

Eric Blake eblake@redhat.com
Wed Mar 30 19:36:00 GMT 2011


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
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_init.html.
 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.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://cygwin.com/pipermail/cygwin-developers/attachments/20110330/633ee574/attachment.sig>


More information about the Cygwin-developers mailing list