Re: [Xenomai-help] rtdm_event_timedwait returns -EINTR

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

Philippe Gerum wrote:
> On Thu, 2009-04-30 at 07:09 -0700, Thomas Lockhart wrote:
>>> Hello, I have a problem with rtdm_event_timedwait() function. It
>>> sometimes ends prematurely with -EINTR error code. It depends on
>>> special circumstances (CPU load, resizing console window in X, ...).
>> In other areas of Xenomai when one sees a EINTR return one should
>> reenter the original call. Like this (?):
>>
>> do {
>>   err = rt_task_wait_period(...)
>> } while (err != -EINTR);
>>
> 
> Just to clarify a few points more:
> 
> Xenomai always tells the kernel that blocking (Xenomai) syscalls
> _should_ be restarted when interrupted by a Linux signal (i.e.
> -ERESTARTSYS is passed down to the kernel by the Xenomai core in that
> case), and the kernel will actually restart that (Xenomai) syscall if no
> handler was installed for such signal, or if SA_RESTART is set in the
> sigaction() flags for the signal.
> 
> In all other cases, the syscall will not be restarted despite the
> "should restart" hint passed to the Linux kernel, and -EINTR will be
> eventually returned by the native API syscall (or errno == EINTR for the
> POSIX skin). The way other skins (e.g. VxWorks) will propagate the
> -EINTR condition on interrupted syscalls to the user program depends on
> their respective API conventions, but they will propagate that
> information in a way or another as well, if the syscall was not
> restarted.
> 
> Additionally, syscalls may be forcibly unblocked via rt_task_unblock(),
> which will cause -EINTR to be returned to the caller as well. This is
> totally unrelated to Linux signal management though.

Are not there cases where the kernel/libc "jumps back" to the beginning
of the syscall when asked to restart a syscall ? Is not it what causes
the problem with rt_event_wait ? In fact if it is the problem then it
means that the user-space skins should always convert delays to an
absolute expiry date, and pass this as argument to the syscall, so that
blindly restarting the syscall will work as expected. However, if that
is the case, it means that we have quite a few syscalls to fix...

Also, from your mail, it is not clear to me, what is Petr problem,
rtdm_event_timedwait ? or rt_event_wait.

-- 
                                                 Gilles.