On Sun, 2004-10-10 at 11:14, Marc Kleine-Budde wrote: > Hi Philippe! > > How does the delivery of linux signals work with fusion thread? > > In Vesuvio, shadow.c registers a ADEOS_SIGNAL_PROCESS handler which > blocks all signals but TERM, KILL, QUIT, INT. These signals are later > processed by the ADEOS_KICK_PROCESS handler. This handler unblocks its > realtime counterpart. Why? > What happens then with the signal and the > shadow process?
Because in this implementation, receiving any of these signals caused the shadow to be deleted. Due to the dual context of a shadow thread (Linux/Xenomai), the best way to do this without encurring stability problems was to let the signaled thread delete itself. For this to happen, you would have to unblock it from any Xenomai wait state first. If you don't, then you would keep a dandling RT context aslept while the Linux one might be destroyed. > If I understand the code all other signals are dopped, > i.e. lost. > Yes, this is how it used to work for signals directed at shadow RT threads in pre-0.6. > 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, 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. For the above to work, blocking skin syscalls must check for the XNBREAK condition upon return from xnpod_suspend_thread() or any of its derivative that can block (e.g. xnsynch_sleep_on()) and return the -EINTR status to the caller. In any case, I feel that this feature is a requirement for a close integration with Linux. This also means that shadow threads have their behaviour now alterable by signals sent from non real-time threads (including job control), but since Linux enforces the permissions, it's completely acceptable. > thanks in advance - marc -- Philippe.
