Re: [Xenomai] EINTR in notifier.c (mercury)

[Matthias Schneider <ma30002000@yahoo.de>]

> On Monday, March 31, 2014 7:50 PM, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:

> > On 03/31/2014 03:18 PM, Philippe Gerum wrote:
>>  On 03/31/2014 01:27 PM, Gilles Chanteperdrix wrote:
>>>  On 03/31/2014 12:34 PM, Matthias Schneider wrote:
>>>>  Hi all,
>>>> 
>>>> 
>>>>  still working on thread suspension in mercury, I noticed that some
>>>>  threadobj_suspend() and threadobj_resume() calls seemed not to have the desired
>>>>  effect. Analyzing the issue, I found out that sometimes the read operations on
>>>>  the pipe in notifier_wait() seem to return with EINTR, especially in
>>>>  heavily loaded systems. Restarting the read system call in that case made
>>>>  thread suspension a lot more reliable in my case.
>>>> 
>>>>  I have attached a patch adding loops to deal with the EINTR situation in all
>>> 
>>>  You can probably avoid testing for EINTR if all signal handlers are
>>>  registered with the SA_RESTART flag.
>>> 
>> 
>>  The app may not explicitly care for signals (granted, most would do, but
>>  we would then have to assume they do it right).
>> 
> 
> Yes, applications may want to use signals to interrupt a call to read 
> and voluntarily get EINTR anyway.
>                         Gilles.


Please find attached a third version of my patch dealing with
EINTR syscalls. Note that I also stumbled over unexpected behavior
in threadobj_sleep and cancel_sync due to EINTRs. Considering that
mercury is using signals for user-space round-robin and thread
suspension, even without any application signals EINTR happens 
quite often.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eintr_3.patch
Type: text/x-patch
Size: 3040 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140406/c4a1fe20/attachment.bin>