Looks like I opened a can of worms!

Part of the impetus for my investigation into Smalltalk’s threading model was running BottomFeeder on OS X. The UI seems to lock up on my machine when retrieving feeds (or possibly posts – I forget). I don’t see the ‘wristwatch’ that a completely frozen smalltalk UI shows in OS X, but all the scroll bars seemed to stop working, and it appeared to queue up all my mouse clicks so that all manner of crazy things happened when the UI came back 🙂 This may have contributed to my initial impression that any blocking IO would block the whole smalltalk process.

That’s more of an aside (although if anyone knows whether BottomFeeder does indeed have this problem on OS X that would be great!). (Later: James kindly responded – it is a known issue in OS X and should improve)

What interests me more generally is how well smalltalk deals with things like high concurrency. Is it possible to implement non-blocking IO? Is it even necessary – can I just fork off an unlimited number of Process objects? Would it be feasible for example to use smalltalk to build a web server that gracefully survives a slashdotting on a powerful commodity pc?

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 🙂