--- Dave Mitchell <[EMAIL PROTECTED]> wrote: > On Wed, May 28, 2003 at 07:58:37AM -0700, Austin Hastings wrote: > > 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. > > And on a multiple CPU box...?
Depends on whether of not you try taking advantage of the multiple CPUs. Now we get into OS-level threads vs. processes, and where the OS is going to support multiprocessing. But in the "most involved case" -- OS threads can span CPUs and still reference a single memory space -- the OS-thread to P6-thread mapping will have to do some sort of locking. My proposal called for locking at the expression level, as well as (of course) tunable locking for individual items. On the one hand, the required amount of locking will raise the cost of running Perl threads in a MP environment. But I think that can be minimised by the compiler knowing when it's in a threaded program. If the MP box with locking is slower than a like SP box, there should probably be a "just-one-user-thread-please" switch. (The MP could still be used to advantage for IO and OS operations by Parrot -- it's just that this particular user program is poorly designed for MP and thus requests C<#! /usr/bin/perl -just-one-user-thread>. =Austin
