Dmitry Adamushko wrote: >>> ... > >> I have not checked it yet but my presupposition that something as easy as >> : >>> preempt_disable() >>> >>> wake_up_interruptible_sync(); >>> schedule(); >>> >>> preempt_enable(); >> It's a no-go: "scheduling while atomic". One of my first attempts to >> solve it. > > > My fault. I meant the way preempt_schedule() and preempt_irq_schedule() call > schedule() while being non-preemptible. > To this end, ACTIVE_PREEMPT is set up. > The use of preempt_enable/disable() here is wrong. > > > The only way to enter schedule() without being preemptible is via >> ACTIVE_PREEMPT. But the effect of that flag should be well-known now. >> Kind of Gordian knot. :( > > > Maybe I have missed something so just for my curiosity : what does prevent > the use of PREEMPT_ACTIVE here? > We don't have a "preempted while atomic" message here as it seems to be a > legal way to call schedule() with that flag being set up.
When PREEMPT_ACTIVE is set, task gets /preempted/ but not removed from the run queue - independent of its current status. > > >>> could work... err.. and don't blame me if no, it's some one else who has >>> written that nonsense :o) >>> >>> -- >>> Best regards, >>> Dmitry Adamushko >>> >> Jan >> >> >> >> > > > -- > Best regards, > Dmitry Adamushko > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Xenomai-core mailing list > Xenomai-core@gna.org > https://mail.gna.org/listinfo/xenomai-core
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
