RE: Threads

["Brent Fulgham" <brent.fulgham@xxxxxxxxxxxxx>]

> If your threads are lightweight (i.e. a single native thread exists
> that manages a number of lightweight thread objects, perhaps more
> typical in VM-based implementations), the choices are limited. You
> pretty much have to farm out native calls to other native threads
> dedicated to that chore in order to keep moving. Once the generic
> infrastructure's in place though, writing native methods in that
> environment isn't much more difficult than it is anywhere else.
> 

This reminded me of the "Stackless Python" extension, with its so-
called microthreading implementation (see http://www.stackless.com/.)
I don't recall all the details now, but they effectively implemented
a (micro)threading system similar to Jonathan's description.

I don't know how useful this work would be, but it might stimulate
some ideas.

A few questions:

1.  Can the availability of multiple processors (on SMP machines)
be taken advantage of without resorting to native threads?

2.  What problems are created when trying to interface with non-Goo
code if Goo's threads are not implemented as "native" threads (e.g.,
if I have, say, a server thread running in Goo that needs to call
a native OS system routine, is it possible to confuse the OS when 
these "micro" threads both call the OS-level routine from within
Goo?

Thanks,

-Brent