On Jan 23, 2008 6:48 PM, Philippe Gerum <[EMAIL PROTECTED]> wrote: > Gilles Chanteperdrix wrote: > > Gilles Chanteperdrix wrote: > > > Please find attached a patch implementing these ideas. This adds some > > > clutter, which I would be happy to reduce. Better ideas are welcome. > > > > > > > Ok. New version of the patch, this time split in two parts, should > > hopefully make it more readable. > > > > Ack. I'd suggest the following: > > - let's have a rate limiter when walking the zombie queue in > __xnpod_finalize_zombies. We hold the superlock here, and what the patch > also introduces is the potential for flushing more than a single TCB at > a time, which might not always be a cheap operation, depending on which > cra^H^Hode runs on behalf of the deletion hooks for instance. We may > take for granted that no sane code would continuously create more > threads than we would be able to finalize in a given time frame anyway.
The maximum number of zombies in the queue is 1 + XNARCH_WANT_UNLOCKED_CTXSW, since a zombie is added to the queue only if a deleted thread is xnpod_current_thread(), or if the XNLOCKSW bit is armed. > > - We could move most of the code depending on XNARCH_WANT_UNLOCKED_CTXSW > to conditional inlines in pod.h. This would reduce the visual pollution > a lot. Ok, will try that, especially since the code added to the 4 places where a scheduling tail takes place is pretty repetitive. -- Gilles Chanteperdrix _______________________________________________ Xenomai-core mailing list Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core