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

Reply via email to