> > In spite your employer does not use them, I'm sure native threads will
> > be needed in some context.
> 
> I don't think it's a closed issue. It's just that no one has yet felt that 
> having native threads is important enough to bother doing all the work 
> required to get them. After all, this is something that would probably impact 
> everything from the VM up through the image.

One other good thing to mention here, is that you can access multiple
native threads with *separate* memory using Dave Lewis's OSProcess
package.  That's not the same as native threads with *shared* memory,
but it is a useful capability that is already implemented.


> I showed that having a higher-priority thread would force timeslicing by 
> preempting lower priority processes.

As an aside, I wish this behaved slightly differently, so that we could
truly say "squeak processes are cooperative within priority levels". 
It's remarkable that few enough Squeakers use multiple
compute-intensitev threads and thus don't seem to notice, but still it
seems worth doing it the best possible.

It's just a matter of putting threads at the front of their run queue
when they get preempted.

The current situation is a worst of both worlds, IMHO.  You get the lack
of timing guarantees of cooperative threading, plus the lack of safety
of preemptive threading.

If we were to make this small change to the schedular, you can still get
preemptive threads back by having a high-priority thread do something
like the following every once in a while (untested):

	procs := Processor waitingProcessesAt: (whatever priority).
	procs isEmpty ifFalse: [ procs first suspend resume ]


More info at:

	True Cooperative Threads?
	http://minnow.cc.gatech.edu/squeak/5684

-Lex