--sdtB3X0nJg68CQEu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 15, 2007 at 02:49:01AM +0200, Mindaugas R. wrote:
> yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
> > - both variants mean additional knowledge for a dispatcher,
> >   and enlargement of the api.
> Well, variant B at least does not add Yet Another API function.
>=20
> >   (it's natural, given that the purpose of the api change in the first
> >   place was to give schedulers more info.)
> Schedulers, but not dispatcher. In sched_enqueue() splitting case it woul=
d be
> also for dispatcher, wouldn't it?
>=20
> > - the variant B puts more knowledge about idle lwps int schedulers,
> >   while the variant A doesn't.
> Agree, scheduler must check for LW_IDLE flag. For the sake of clearness, =
one
> could pass a NULL for sched_switch(), which would mean to not enqueue.
>=20
> > is your specific scheduler implementation easier with the variant B?
> Both cases are equal.
>=20
> > - the variant B introduces implicit enqueue, while the variant A doesn'=
t.
> Yes, but it's a single case. You've said that sched_switch() is a "method=
",
> but one could say, this function is designed especially for mi_switch().
>=20
> In essence, I am OK with both variants, because practically they are (and=
 will
> be) equal - it is just a question of theoretical abstraction. Does it rea=
lly
> worth adding additional function into the API for single use from very
> concrete place in mi_switch()?
> If you really think that yes - OK, it could be changed, because we could
> argue about such details all night.. :)
>=20
> P.S. Hey, where is the 3'rd voice in such cases?

I am only partially following the discussion, but I think that the best=20
choice is option A. While it does add a new routine to the API, my limited=
=20
understanding is that it makes the distinction, which we need to make,=20
very clear. My personal experience is that when we muddle things together,=
=20
we arrive at code that's harder to maintian in the long run.

Take care,

Bill

--sdtB3X0nJg68CQEu
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFF+J2SWz+3JHUci9cRAgytAJ92vgsEVNVoiQCWIj02tJjyp16+lgCfftdg
8XEEtUpc1GWNUuHKdAGZcYA=
=bi7Y
-----END PGP SIGNATURE-----

--sdtB3X0nJg68CQEu--