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

On Tue, May 22, 2007 at 06:41:17PM -0700, Matt Thomas wrote:
>=20
> On May 22, 2007, at 6:02 PM, Nathan J. Williams wrote:
>=20
> >Rhialto <rhialto@falu.nl> writes:
> >
> >>I'm probably missing something here, because it seems too obvious :-)
> >
> >The SA/pthread library uses the stack as the thread ID, essentially,
> >so things like locking wouldn't work properly, because the lock owner
> >would be wrong.
>=20
> Is there any reason why UNBLOCK upcalls couldn't be delivered on the
> unblocking thread's stack?  It's there, it's available, and it's
> not going to be used until that thread is unblocked.  and if it is
> immediately unblocked, you're already there and running and can just
> setcontext :)

I think the problem is that upcalls can get preempted (interupted). Given=
=20
that we figure out the thread ID from the stack, we now have two different=
=20
blocked contexts here. I think this will make the "detecting interrupted=20
critical paths" code more difficult.

Take care,

Bill

--VywGB/WGlW4DM4P8
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD4DBQFGU6WxWz+3JHUci9cRAgCSAJ9YcJY/TSxZTZgCTU5eXJ7Y+II86ACY+Dor
OjYSF9XyuZjT3aP7iqw21g==
=9OBl
-----END PGP SIGNATURE-----

--VywGB/WGlW4DM4P8--