From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <49F9C374.1040209@domain.hid> Date: Thu, 30 Apr 2009 17:27:48 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <200904301508.29432@domain.hid> <200904301509.13094@domain.hid> <200904301510.8382@domain.hid> <200904301511.15875@domain.hid> <200904301512.9035@domain.hid> <200904301513.12716@domain.hid> <200904301514.6099@domain.hid> <200904301515.16182@domain.hid> <200904301516.696@domain.hid> <49F9B123.7080203@domain.hid> <1241103352.26544.177.camel@domain.hid> In-Reply-To: <1241103352.26544.177.camel@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] rtdm_event_timedwait returns -EINTR List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Philippe Gerum Cc: Petr Cervenka , xenomai-help 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.