> yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
> > you actually splitted enqueueing action by the purpose, didn't you?
> No, I would not call it so, because from dispatcher you see and use only one
> and the same sched_enqueue().

definitely, sched_switch is another method to enqueue.

> > i do not understand the point to make it a part of sched_switch.
> > implicit enqueue is confusing and should be avoided if possible, IMO.
> Ok, understood. I fully agree, but in this case one could:
> a) Split enqueueing into the two purposes as you suggest, which means
> additional knowledge of purpose for dispatcher (what is unwanted) and
> enlargement of API.
> b) Define that sched_switch() must do enqueue i.e. give this anxiety to
> scheduler.

i really don't understand what's the benefit of the B variant.
otoh, i don't understand what's wrong with the A variant either.

- both variants mean additional knowledge for a dispatcher,
  and enlargement of the api.
  (it's natural, given that the purpose of the api change in the first
  place was to give schedulers more info.)

- the variant B puts more knowledge about idle lwps int schedulers,
  while the variant A doesn't.

- the variant B introduces implicit enqueue, while the variant A doesn't.

can you give me an example where the variant B is better?
is your specific scheduler implementation easier with the variant B?

> Keeping in mind, that sched_switch() is called only from mi_switch(), and
> probably will be called _only_ from there, I don't think that B variant could
> confuse somebody, especially when there is a comment in that single place.
> What do you think?

the same argument can apply to the A variant, right?

YAMAMOTO Takashi