On 11/05/2012 07:46 PM, Gilles Chanteperdrix wrote: > On 11/05/2012 02:33 PM, Thierry Bultel wrote: > >> Le 11/10/2012 10:05, Gilles Chanteperdrix a écrit : >>> On 10/10/2012 03:57 PM, Philippe Gerum wrote: >>>>> Except if we invent another scheduler lock service, simply for the >>>>> purpose of spinlocks where suspending the spinlock holder does not make >>>>> sense anyway. >>>>> >>>> >>>> Oh, well, ok. Ack. >>>> >>>> Let's just make sure that we can fold the whole thing into a single set >>>> of services at some point in 3.x though. >>>> >>>> The core issue is that we should not even have to expose a scheduler >>>> locking service to userland, but emulating traditional RTOS APIs >>>> requires that. What a braindamage counter-feature for a real-time system >>>> when one thinks of it. >>> >>> I think we can have the cake and eat it. The idea is to follow the >>> approach in the patch I sent, merged with the one you commited, but >>> simply, in xnpod_suspend_thread, clear the XNHELDSPIN (misnomed if used >>> for that), and simply when we wake up, re-set the bit in the scheduler >>> if the thread preemption count is not 0. >>> >> >> Hi, >> sorry to come on that thread again, but it is not clear to me if the >> issue has been adressed or not. >> I have noticed the "nucleus: introduce internal sched locking helpers" >> commit, that seems related but I am not sure. >> Sorry for the noise. > > > I have posted a patch, and await Philippe's approval. The patch may have > some dubious side effects, it is here: > > http://www.xenomai.org/pipermail/xenomai/2012-October/026523.html >
Yes, I'm late once again. The patch has some problems, so please hold this for now. -- Philippe. _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
