[Xenomai] EINTR in notifier.c (mercury)
ma30002000 at yahoo.de
Sun Apr 6 13:11:42 CEST 2014
> On Monday, March 31, 2014 7:50 PM, Gilles Chanteperdrix <gilles.chanteperdrix at 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.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3040 bytes
Desc: not available
More information about the Xenomai