Smalltalk Tidbits, Industry Rants

I'm glad in CST "all threads are green" - I hate when those red and blue threads in other environments screw up my color scheme.

More seriously, I'm surprised to see you using a term from the Java camp, instead of something less jargony like "user-space cooperative threading"; nice guy Peter van der Linden explains the origin of the term:

When Java 1.0 first came out on Solaris, it did not use the native Solaris library libthread.so to support threads. Instead it used runtime thread support that had been written in Java for an earlier project code-named "Green." That thread library came to be known as "green threads."

Finally, does "Java native threads" in the code really mean OS-native threads, or green threads in the JVM?

Finally finally, are you sure VisualWorks threads don't show up in the process table? You could actually "overwhelm the platform" if you fill that table up with thousands of entries.

Finally finally finally, I ask everyone to please refrain from reviving the stupid "cooperative vs. preemptive multitasking" holy war from ten years ago. Neither approach is dominant.

VW Threads are a purely Smalltalk creation, so they won't end up in the platform process (or thread, as the case may be) table. Try this code while looking at a list of processes/threads in the platform:

| all |
all := OrderedCollection new.
1 to: 1000 do: [:each | | value |
     [value := each factorial.
     all add: (each -> value)] forkAt: Processor userBackgroundPriority].
all inspect 

Hmm... I don't understand one thing: if VisualWorks doesn't have native threads, then what do you do about blocking I/O? Doesn't this block your whole GUI or the whole VM? Is there some M:N scheme available? (The Jikes RVM (a Java VM written in Java) uses this; bascially on a machine with n CPUs they use n native threads, as far as I know).

BTW: I find it surprising that you advocate restricting flexibility and power (native threads) with the argument "Developers might have think a bit to use it right and not shoot themselves in the foot". From reading your blog, I'd gathered that you think that's what Smalltalk is all about.

Sockets are non-blocking at the VM level, and the GUI is all emulated - so you don't get platform blocking. Actually, the issues with providing native threads to developers via ST process --> platform thread is not a "restrict power" issue. It's an implementation issue, and a "how fast can we provide an answer" issue.

The existing VM - especially in areas like garbage collection - makes assumptions based on single threadedness. Changing that at the VM level is harder than doing the equivalent thing at the Smalltalk level via multi-process communication libraries.

murphee wrote: what do you do about blocking I/O?
See VisualWorks THAPI

Simple - run more than one image (process) and have them communicate as needed
That's the old approach used with Erlang (a language designed for massively concurrent applications) but for several years they've been wondering how to make better use of multiple cpus
A Parallel and Multi-threaded Erlang Implementation

If neither, why would you want to skin one?

Comment by Terry

Murphee

I think you misunderstood James' response. The VW process model is very flexible. The process scheduler has a list of priority queues. It always runs the process at the highest priority that is at the front of the queue. A process is suspended only if a higher priority process is available to run or it relinquishes control. This makes for predictable execution.

If a developer wishes to have some processes execute in a round robin fashion, it is a simple matter to create a high priority process that periodically suspends the appropriate process and rearranges processes in the queue.

Seems like we're making the common mistake of conflating parallelism and concurrency. If we want to enable multiple things to happen without blocking one another, then we're looking for concurrency and we can use lightweight language ('green') threads. If we want to take advantage of multiple CPUs (i.e. speed things up) then we need to use platform native (kernel) threads. Doesn't that make it easier?

So what does Smalltalk on Windows do when it needs (for example) to do DNS lookup? Does it implement its own async DNS client because Windows doesn't provide a non-blocking one?

Comment by James Robertson

At present, DNS lookups do, in fact, block at the VM level. We are implementing an asynch client for in order to deal with that OS level limitation.

Comment by Alan Knight

As I recall, DNS is not re-entrant anyway.

I'm not sure what you mean by "reentrant" here. Different people use different meanings for this word in the multi-threading world, so I don't want to assume any single one.