What I think _could_ be useful is to be able to have multiple instances
of ProcessorScheduler, each potentially mapped to a separate physical
processor on the host system -- how precisely this is accomplished in a
particular OS I leave to the interested implementer. ;-) I would assume
that native threads could accomplish this on most OSes capable of
actually using multiple cpus.

Within an instance of ProcessorScheduler, you should be able to work
with lightweight Squeak-native processes just as one does now. It
wouldn't normally be a matter of creating hundreds or thousands of these
instances - less than ten would probably be adviseable.

-- Dwight

"David T. Lewis" wrote:
> 
> On Tue, Jun 06, 2000 at 11:45:04AM -0400, Bijan Parsia wrote:
> >
> > However, a "native threads access" package *would* be nice...maybe
> > something like, oh, I don't know, the OSProcesses package ;)
> >
> FYI, the OSProcess package gives access to heavyweight processes,
> and currently supports only Unix type systems. For example, you can
> "fork" a clone of a Squeak process in a separate operating system
> process, with completely separate address space.
> 
> OSProcess does not give access to a threads package. I could probably
> add this, but to be honest I don't know that it would be very useful;
> I think this is mostly an academic debate.
> 
> Dave