Philippe Gerum wrote:
> Philippe Gerum wrote:
> > Gilles Chanteperdrix wrote:
> >
> >> Gilles Chanteperdrix wrote:
> >> > This is not the only situation where a thread with a nucleus
> >> suspension
> >> > bit need to run shortly in secondary mode: it also occurs when
> >> > suspending with xnpod_suspend_thread() a thread running in secondary
> >> > mode; the thread receives the SIGCHLD signal and need to execute
> >> shortly
> >> > with the suspension bit set in order to cause a migration to primary
> >> > mode.
> >> > > So, the only case when we are sure that a user-space thread can
> >> not be
> >> > scheduled by Linux seems to be when this thread does not have the
> >> > XNRELAX bit.
> >>
> >> From all the bits in XNTHREAD_BLOCK_BITS, only when the XNPEND bit is
> >> set, a thread can not be running in secondary mode. Hence the proposed
> >> patch.
> >>
> >
> > Almost ok, but XNDELAY might also be set alone, indicating a purely
> > timed wait state (i.e. without sync object to pend on, so XNPEND is off).
> >
>
> Forget about this: XNDELAY might also be a transient bit like XNSUSP, so you
> are
> right, we cannot test it there.
Ok. The patch is applied to svn trunk.
--
Gilles Chanteperdrix.
