RFR: 8087322: Implement a Semaphore utility class
Dean Long
dean.long at oracle.com
Wed Jun 24 23:49:23 UTC 2015
On 6/24/2015 4:32 PM, David Holmes wrote:
> On 25/06/2015 9:07 AM, Kim Barrett wrote:
>> On Jun 24, 2015, at 6:39 PM, David Holmes <david.holmes at oracle.com>
>> wrote:
>>>
>>>>> sem_trywait can also fail with EINTR.
>>>>
>>>> Will fix the assert.
>>>
>>> trywait can't fail with EINTR as it does not block - so nothing can
>>> be interrupted.
>>
>> When dealing with standards like POSIX, I generally try to listen as
>> closely as I can to what the standard says, rather than trusting my
>> intuition about how something "ought" to work. Compiler and library
>> authors are known for driving trucks through holes in one's intuition,
>> and then saying nyah, nyah to complaints.
>>
>> So when POSIX says sem_trywait can return an error of EINTR and my
>> intuition says "no way", *I* still include the check. YMMV.
>
> <sigh> The POSIX spec is somewhat inconsistent on the matter:
>
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/sem_trywait.html
>
>
> It states explicitly:
>
> "The sem_wait() function is interruptible by the delivery of a signal."
>
> Nothing about trywait - which makes sense as trywait never actually
> waits - but also says in the ERRORS section that trywait may fail if
> interrupted by a signal.
>
> So yes we should check for EINTR on the trywait - and retry I guess?
Retry doesn't sound necessary for trywait, and an unbounded number of
retries sounds bad. I would think one attempt is enough.
dl
More information about the hotspot-dev
mailing list