On Sun, 2004-10-10 at 22:14, Marc Kleine-Budde wrote: > On Sun, Oct 10, 2004 at 08:14:14PM +0200, Philippe Gerum wrote: > > > How does the delivery of linux signals work with fusion thread? > > [...] > > > > In Fusion, there isn't a ADEOS_SIGNAL_PROCESS handler. Does that mean > > > that all signals are delivered the by the linux-kernel? Does this > > > include a migration from the realtime to linux? If, where? > > > Yes. The new implementation since 0.6 ensures that Linux keeps deciding > > for the appropriate actions to take upon a signal that has been received > > for any Linux task, even if it is mapped to a shadow RT thread. This is > > far more robust and preserves the signal semantics for user-space apps. > > The latter was a prerequisite to obtain a decent GDB support for > > real-time threads in user-space because you have to relay the SIGTRAP > > signal properly for this; but not only: as Jan pointed it out recently, > > He sent me a copy of this thread today :) > > > allowing apps to decide for their own handling of signals > > even/especially for real-time threads is needed for them to properly > > perform cleanup actions and so on. > > > To this end, 1) the kick handler (wired to Linux's signal_wake_up()) > > unblocks any signaled shadow that happens to be sleeping; 2) the nucleus > > detects that a shadow has been unblocked upon return from a Xenomai > > syscall, and attempts to setup a restart condition conforming to the > > Linux convention when applicable (see request_syscall_restart()'s > > handling of ERESTARTSYS). The latter includes relaxing the unblocked > > shadow so that the signal handlers or default actions could be run in > > the proper context. > > I see - But what happens to hardened linux tasks who just working in > RT-userspace? A reschedule 'only'? > > ---------------<xnshadow_kick_process>--------------------- > if (thread == thread->sched->runthread) > xnsched_set_resched(thread->sched); > [...] > xnpod_schedule(); > ----------------------------------------------------------- > > They don't get the XNKICKED flag set...AFAICS in the nucleus scheduler > there isn't a test for signals_pending() - At least no test for > linux-signals, only for xenomai or are both connected in a way I've > overlooked? When will the threads in this state be relaxed? >
No, they are not connected. Linux signals can be handled over the Linux context only. The flow of control is as follows: o Linux sends a signal to a Linux task mapped to a shadow thread; so the current CPU must be operating in relaxed or idle mode. o xnshadow_kick_process() intercepts the call to signal_wake_up(), and wakes up the associated shadow thread if it is currently blocked in hardened mode on a nucleus wait channel. In such a case, the shadow is forcibly unblocked. o the shadow resumes execution in hardened mode, and the interrupted blocking service checks for the XNBREAK condition raised by the unblocking service (xnpod_unblock_thread()), and returns -EINTR. o given that the interrupted system call was issued by a user-space RT thread (otherwise it's a non-issue), then the awaken thread returns to the syscall demultiplexer in shadow.c, and sets up the syscall restart condition appropriately when applicable (i.e. signal_pending() and -EINTR returned by the blocking syscall). At this point, the running shadow is forcibly relaxed, so that Linux gets back in control. o the Xenomai syscall (which has been interrupted) then returns through the normal Linux syscall exit path, which handles the pending signal, fires the handler or runs the default action. > Marc -- Philippe.
