On Sun, Oct 10, 2004 at 10:52:16PM +0200, Philippe Gerum wrote: > > > > How does the delivery of linux signals work with fusion thread?
> > 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. Bar works hardend in RT-Userspace, higher priozied foo gets unblocked due to the end of a timer, foo's code contains a kill(<pid-of-bar>, 2), foo gets migrated into linux-domain during delivery of the syscall, signals is delivered to bar, resulting in this: > 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. bar is not blocked... What happens then? > 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. bar's shadow continues eventually in hardend mode, no XNBREAK due to no blocking, no -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. bar was not in a systemcall...where is the signal_pending() check for this case? > 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 -- #!/bin/sh set - `type $0` 'tr "[a-zA-Z]" "[n-za-mN-ZA-M]"';while [ "$2" != "" ];do \ shift;done; echo 'frq -a -rc '`echo "$0"| $1 `'>$UBZR/.`rpub signature|'`\ echo $1|$1`'`;rpub "Jr ner fvtangher bs obet. Erfvfgnapr vf shgvyr!"'|$1|sh
