Here are some of my mostly random thoughts about this:

Yes, this seems to be highly non-trivial to me.
But in times of multi-core CPUs popping up everywhere
(even under my desk), it would certainly make GNU
smalltalk even more interesting.

But I guess there will be big issues with the GC
and the I/O subsystem.

I also wonder how the API would look like on the
smalltalk side. Can I specify which thread is a
"real" thread? What kind of locking can I use?

Will the VM crash on me when I write to an object
at the same time? Are there alternatives?

My opinion is that locking and synchronizing should
be up to the Programmer. Thread programming and
synchronization is a very complicated thing and there
is afaik no easy way out. Let the programmer decide
wheter he needs real threads and when he needs
synchronization.

I just wanted to say that IF I get real threads somehow
in smalltalk, I want to control which [] fork results
in a real and which in a pseudo-thread. And that
if I mutate an object in two "real" threads at the same
time (without locking) I deserve a segfault and core dump
or corrupted data.

It's not "impossible", and with OpenMP support in GCC it can actually be done, I think. Not anytime soon, though. :-)

You could make the bytecode interpreter variables thread-local and put the context switching into a critical section (i.e. only one kernel thread could perform a green thread context switch, at a single time). GC and object allocation could also be put in a critical section. If you can make sure that message sends can be executed concurrently, that would be great. I/O is not complicated, because it is already asynchronous.

As I said, the easiest design would stop execution completely at GC time. But *within* GC you can do some tricks. For new-space collection, you could parallelize searching for roots in the grey pages. Mark'n'sweep is slow, and at least the mark phase could be parallelized.

So, there are a few small opportunities here and there besides the "big thing".

Replying to Robin, who "wants to control which [] fork results in a real and which in a pseudo-thread", I say that I disagree strongly; I'd want M:N threading (where N is the number of kernel threads and M is the number of green threads) instead.

That's because Smalltalk processes are already pre-emptive, though by default there is no time-sharing. So, you need proper locking now too.

Suppose you have two processes P and Q modifying one variable. A third one, R, has lower priority than the first two and is waiting on a Delay. While P process is modifying the variable, the Delay fires, and the high-priority timing process is woken up. This puts to sleep P and sends it to the back of its ready-list. You guessed right: when the timing process goes back to sleep, Q is at the beginning of its ready-list, and it can see the variable in a half-modified status.