I think the most peoples' motivation behind wanting native threads is to
allow Squeak to use multiple processors to increase performance.  Having
every Squeak process run in a separate OS thread would certainly hurt
performance (unless you have more physical processors than you have Squeak
processes).  Creating more OS threads than processors is a waste and should
be avoided.

How does the Java VM make use of OS threads?  Does it create more OS threads
than processors?  That would be bad.

Mark Guzdial wrote:
> - Process interactions, like semaphores.  Java has lots of overhead
> in order to let the VM completely handle threading.  There is a
> lock/unlock operation available on each and every object in the Java
> VM (i.e., essentially each object becomes a monitor), which is an
> awful lot of VM-level overhead, it seems to me.

In effect, because the Squeak VM uses only one OS thread for the interpreter
loop, Squeak objects are automatically monitors.  It would be interesting to
have the VM automatically create one interpreter thread for each processor,
and then modify the wait, signal, resume and suspend primitives to
automatically utilize those threads...and, implement an object level locking
mechanism similar to Java to make sure each object is a monitor.

Also, correct me if I'm wrong, but Squeak does *not* have preemtive
scheduling does it?  I don't think any process can be interrupted
preemtively except via the user interrupt semaphore correct?  Would it be
possible to do something like the user interrupt, but based on a timer to
get a close approximation of preemptive scheduling?  On a related note,
could Delay class>>#primSignal:atMilliseconds: be made to happen
preemptively?  If so, that mechanism could be used to implement preemptive
scheduling.

For example, it would enable code like the following to work:

| tmp |
tmp _ Processor activeProcess.
[
	(Delay forSeconds: 3) wait.
	tmp terminate.
] fork.
[ true ] whileTrue: [ 1 + 1 ].

...which should allow any sort of time based preemtive scheduling desired.

- Stephen