Stephen Pair wrote:

> > >And, InstructionStreams are really the fundamental unit of processing and
> > >should take much of the responsibility currently held in Process.
> > >Especially when considering how one would architect a Squeak that takes
> > >advantage of multi-processor CPUs.
> >
> > Is such work underway?  My intuition tells me that this would be
> > related to
> > implementation of a Smalltalk which would be multithreaded on a
> > single CPU
> > (which would be great).
>
> Not that I am aware.  Making Smalltalk multi-threaded is tricky.  Some
> Smalltalks have taken the approach of making the "Process" concept in
> Smalltalk equate one-for-one with OS threads.  I think that approach is very
> bad.  First, it's difficult to implement, and second, it's inefficient
> because you have the additional overhead of the OS context switching.

<more good thots snipped>

I agree with Stephen. I do not think that just making all Smalltalk processes
map 1:1 with OS threads is a good idea. The Smalltalk virtual machine is
conceptually a single processor machine. Note the presence of one instance of
Processor. Where I would like the line to be drawn is in the Processor class.
IOW, if you really want two or more OS threads, you create an instance of
Processor for each one. If you have a multi-processor machine, then you can
create one Processor object which has an underlying VM OS thread per to run on
each physical processor. But you can pretend you're a multiprocessor machine on
any OS that supports OS threads.

In short, I'm not arguing for or against using OS threads, but rather trying to
make a case that the correct association to make is between OS threads and
instances of Processor (not Process).

--
Travis Griggs (a.k.a. Lord of the Fries)
Member, Fravenic Skreiggser Software Collective
Key Technology
P-P-P-Penguin  Power!