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

On Sat, Feb 17, 2007 at 09:55:12PM -0800, Bucky Katz wrote:
>=20
> Let me rephrase the question: If the only thing that changes was the
> implementation of primitives, why does m:n have to come out? On the
> other hand, if more changed, why do you think that just implementing
> the primitives is enough to fix an arch?

I think that implementing the primitives will fix an arch for compilation,=
=20
thus the (implied) use of "just".

The other question, though, needs an answer. In great NetBSD tradtion,=20
I'll offer one, even though I may not be the best to answer. :-)

I'll be honest, I was disapointed to learn that we were dropping m:n
pthreads by reading source-changes. So I good-heartedly berated Andrew
about it.

What I learned is that the main issue is the SA code is not MP-safe. The=20
kernel code relies far too heavily on big-lock. Simply put, we botched=20
making the SA code MP-safe.

Well, the point of new-lock is to make the kernel away from big-lock. So=20
the threading code needing big-lock will not do.

Nathan didn't have the time to fix it, nor did Andrew. We've discussed
these issues in the past, and no one else has been able to fix them. I've
looked into it on occasion, and achieved nothing each time as well. So the
thought that we wouldn't be able to fix our SA code to be MP-safe seemed
fairly clear. In retrospect, I wish we'd known that you might be in a
position to help fix SA. Things would probably been handled differently.

Specifically, my understanding is that the SA code is very sloppy about=20
memory allocation, and allocates memory at times when it really shouldn't.=
=20
It only works because we use big-lock. As we move to having interrupts and=
=20
such run w/o big-lock, things will explode.

Also, we need some sort of smart Virual Processor allcoation code.=20
Otherwise we really need a VP per running thread, in case the thread=20
stalls. And that really defeats the purpose of m:n's stack savings. :-(

As to the long-term options for SA, I'd love it if someone would fix it.=20
The system calls are still assigned, and the calls can be re-added once=20
there's a good implementation. I'm not 100% sure how we'd live w/ two=20
libpthreads, but I'm sure we can figure it out.

So if you can get SA working, please do!

Take care,

Bill

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

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

iD8DBQFF2AFzWz+3JHUci9cRAr9NAJ4t6ktrceif7dLzdVCyMEusVG7btgCbBMAd
dRz5NAh02QK3rZ2+DEsmqGY=
=3Fkj
-----END PGP SIGNATURE-----

--jCrbxBqMcLqd4mOl--