yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
> > yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
> > > i prefer to have separate calls for separate operations.
> > > ie. "enqueue for yielding" and then sched_nextlwp().
> > What is the negative point, except the incorrect name, of current variant?
> > I am not sure what is the benefit of adding such additional things, except
> > "yet another function in API". Of course, it could be structurization and
> > abstraction, but in this case such separation would be more scheduler
> > dependent, rather than generic, thought.
> 
> can you explain how the separation is scheduler dependent?
> i'm not happy with putting more knowledge about idle lwps into schedulers
> unnecessarily.
I may be wrong, but...
In such case you would declare two states - "enqueue for yielding" and
"enqueue for the rest", which would be for specific scheduler internals. As
an abstraction, dispatcher should not know about such transitions, it should
only know that it could - enqueue or dequeue.
What is not entirely clean in this case, that we are with one foot in the boat
and other is in the ground - i.e. doing the enqueue in sched_switch(), but
leaving dequeue for dispatcher. If move dequeueing part into the
sched_switch(), then dispatcher could know three things: enqueueing,
dequeueing and switching. But doing so is not convenient...
About idle LWPs knowledge in schedulers: the rule is that they should not
touch them (checking of LW_IDLE flag). Do you want to do such checks only
in dispatcher? In idle LWP case, we could pass the NULL for sched_switch(),
just it would be an additional if() check :)

-- 
Best regards,
Mindaugas
www.NetBSD.org