On Tue, May 27, 2003 at 02:05:57PM -0700, Michael Lazzaro wrote: > > On Tuesday, May 27, 2003, at 01:16 PM, Austin Hastings wrote: > > 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. > (snip) > > 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.
See, this where I start to feel all Cozeny and wonder what the heck we're doing even thinking about how it's implemented. What I want to know is how it looks from the user perspective. If, in order to understand threads, I have to first understand coroutines, I think that's a loss because it throws away (or at least morphs into an unrecognizable form) all of collect CS knowledge of what "threading" usually means. In other words, I think the idea of fork-like behaviour is important to threads. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
