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

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to