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.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to