--- Dave Mitchell <[EMAIL PROTECTED]> wrote: > 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.
On a single-CPU box, the OS level threads could easily be used to support blocking operations feeding back to async I/O, while all "real work" (execution of opcodes) was done in a single thread. Parrot could elect to implement threading on its own. In fact, if consistency of execution is a design objective, it probably should. > 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. It should be possible (if Parrot is in charge of threading) to guarantee pretty sweet behavior -- "context switches" only happen a "good moments" when it's easy to do. That should improve speed quite a bit. =Austin > Blaming Islam for 911 is like blaming Christianity for Oklahoma City. Replying to this tagline would likely start an incendiary discussion unlikely to be considered appropriate for the list. Are you sure you need to troll here?
