On Tuesday, May 27, 2003, at 01:16 PM, Austin Hastings wrote:
(snip)I like and agree with some of what you've been saying. I too think that there's a case of "an x is just a y with ..." underlying the whole coro/thread/parallel thing. That's why I'm in favor of deconstructing the threading thing -- a lower thread overhead means more people can spawn more threads for lower cost.
So with that in mind, see my enormous proposal from April 15th. I think that coroutine behavior could be coded with the stuff I proposed, maybe with a few helper items added in.
Yes, I just re-read it. Of what you wrote, the one thing I'd like to think extra hard about is whether we really _need_ the fork()-like behavior of threads, at all. No, seriously. Stop laughing!
If we could think about "threads" not in terms of forkyness, but simply in terms of coroutines that can be called in parallel, it should be possible to create an implementation of "threading" that had to do a whole heck-of-a-lot less duplication of state, etc. Things "outside" the scope of the thread group would automatically be shared(?), things "inside" the thread group would not be shared unless explicitly marked as such.
Which, if I read it right, is what you proposed too, but with a slightly different syntax.
That _might_ make threads a heck of a lot faster upon creation/startup, and a lot less bulky in general.
MikeL
