On Tue, May 27, 2003 at 02:05:57PM -0700, Michael Lazzaro wrote: > 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.
But underneath, these pretty coroutiney/virtual-threads still have to to be implemented in terms of the underlying OS's real threads, so parrot will have to start being really clever applying locks and mutexes all over the place to all those outer bits that are shared etc. So while you may get a cleaner high-level interface to threading behaviour, I don't think you're gonna gain speed and or bulkiness. But I could be wrong. Stranger things have been known :-) -- Blaming Islam for 911 is like blaming Christianity for Oklahoma City.
