--- Michael Lazzaro <[EMAIL PROTECTED]> 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. 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.
Right. My call was that we should share everything except the innermost context -- and that was just to allow the coder to keep some status variables differentiating parent from child. > > That _might_ make threads a heck of a lot faster upon > creation/startup, and a lot less bulky in general. That's the Objective: I want both "implicit threading" -- cases where the interpreter could automatically spawn off parallel processing without being invited to -- and "explicit threading" to coexist. =Austin
