Gilles Chanteperdrix wrote: > Philippe Gerum wrote: >>>> In short, the following patch against 2.3.0 stock fixes the issue, >>>> allowing threads to block while holding the scheduler lock. >>> Ok, but this means that the skins which use XNLOCK with the previous >>> meaning need fixing. >>> >> >> Only those which really wanted - i.e. by design - to return an error >> flag (or the board to lockup or panic) in case of a thread going to >> sleep while holding the schedlock. This change does not affect the >> schedlock semantics otherwise. >> > > I do not understand how it works, I mean, how do you know, in > xnpod_schedule, if xnpod_schedule was voluntarily called by the current > thread, or was called upon reception of an interruption ?
sched->inesting manages the scheduler lock in interrupt context (and XNLOCK requires Xenomai thread context anyway - something an interrupt handler cannot expect). So that part is not affected by the XNLOCK changes. Jan
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core