This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Threads in Smalltalk
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
Darren Hobbs asks about threading strategies in Smalltalk relative to the ones he knows in Java:
For example with the latest release of Java you might use the nonblocking IO library and one thread per cpu, keeping all the cpu's maxed out without thread-switching, so your only bottleneck is available memory (and browser timeouts). Is there an idiomatic smalltalk equivalent?
My usual tactic for maximising throughput is to minimize the number of thread/processes running, and only hand off to another process when you would otherwise have blocked, for example on IO. Nonblocking IO support in java allows me to use just one thread for all an application's network IO, and keep the rest of the threads as busy as bandwidth allows. I don't know how to do this in smalltalk, nor even if I'm worrying about the right problem in smalltalk
The primary difference (at least with respect to VisualWorks) is the nature of threads in the language. In Java, threads (usually) map directly to OS level threads. That means that you have to manage them carefully; create too many and you'll just spike all available CPUs. In VisualWorks, threads are lightweight (green) threads within the context of a single heavyweight Smalltalk process. That makes them nearly free from an overhead standpoint.
In the context of something like a web server, this is especially true - the server I host the twenty Cincom Smalltalk blogs on is running the VisualWorks web application server, and handles a decent amount of traffic. Here's how things work in the server itself:
There's a listener process - this one sits on the application server's inbound port, waiting for connections. It runs at a high priority (70, where the scale in VW runs from 1 to 100). As connections come in, the server determines who (i.e., which web application) should handle each one. As soon as it determines that, it forks off a Smalltalk process at 50 to handle that connection, and then goes back to listening. This scales pretty well; we have yet to see any kind of issue in this server, and many of our customers handle much higher loads than we do.
Now, when I say "threading in Smalltalk", I have to be careful which Smalltalk I'm talking about. Cincom Smalltalk consists of VisualWorks and ObjectStudio - ObjectStudio maps Smalltalk processes to native threads. In VisualWorks, we can use native threads when spinning up an external API call - so we can make sure that database calls (for example) don't block the VM (important for a server!). Native threads have their own issues; when engineering ported Opentalk from VW to Opentalk, they ran into a few problems:
As a developer, you have far less control over native threads than you do over green threads
minimal ability to set priority
if a native thread crashes, it can take down the entire system - a green thread crash can be handled easily via standard exception handling
Other Smalltalk implementations vary as well. Squeak and VisualAge are like VW - green threads for Smalltalk processes, and in VA, the ability to map an external API call to a native thread. Smalltalk MT, like ObjectStudio, maps Smalltalk processes to native threads. I'm not entirely certain what Dolphin does; I think it uses green threads. In any case, the point is that it varies by implementation.
Previous Topic
