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

On Tue, May 22, 2007 at 01:57:44AM +0200, Rhialto wrote:
> On Fri 18 May 2007 at 11:42:28 -0700, Bill Stouder-Studenmund wrote:
> > On Fri, May 18, 2007 at 02:52:31PM +1000, Daniel Carosone wrote:
> > >  If the upcall in question tells libpthread that the lwp has been
> > >  blocked, the upcall stack doesn't get recycled to process more
> > >  upcalls until the lwp later unblocks.
> >=20
> > I don't think that's fully correct.
> >=20
> > There are two different stacks involved. There's the stack of the threa=
d=20
> > that was running, made a system call, and got blocked, and then there's=
=20
> > the stack for the upcall telling libpthread about the blockage.
>=20
> Why do these need to be different stacks? I would think that a blocked
> stack would make a perfect candidate for temporary use for upcalls.
>=20
> I'm probably missing something here, because it seems too obvious :-)

The big issue is you then have two different contexts of code running on=20
one stack. That muddles concepts that are otherwise distinct.

How do we talk about them as separate things if we muddle them?

Right now we have a mapping that takes us from a user stack to figuring=20
out which thread is operating. If we were to just do what you describe,=20
we'd now have two distinct things (the blocked thread and the upcall=20
telling us about the blockage) yet we couldn't differentiate them.

There's also the practicle issue that upcalls can get interrupted. We have=
=20
code to handle it. The problem is that if the "This got blocked" upcall=20
ran on the same stack as the blocked thread, then we couldn't tell them=20
apart. If an upcall gets blocked, we want to resume it. But we don't want=
=20
to resume the blocked thread...

So they really do need to be separate.

Take care,

Bill=20

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

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

iD8DBQFGU3ZgWz+3JHUci9cRAqC1AJsEknjvwbYx4Wa+m4nhC9SdpHa8GgCfaFtq
DXG41uMPRid2i8+H27q1zvk=
=jJJG
-----END PGP SIGNATURE-----

--IS0zKkzwUGydFO0o--