. .


A Smalltalk Thread Pool

July 29, 2010 8:22:25.663

Ramon Leon talks about his implementation of a thread pool for Smalltalk (in the context of a Seaside app):

I had a search result page in Seaside that launched about 10 background threads for every page render and then the page would poll for the results of those computations, collect up any results found, and AJAX them into the page. Each one needs to run in its own thread because any one of them may hang up and take upwards of 30 seconds to finish its work even though the average time would be under a second. I don't want all the results being stalled waiting for the one slow result, so it made sense to have each on its own thread. This worked for quite a while with nothing but simple forking, but eventually, the load rose to the point that I needed a thread pool so I could limit the number of threads actually doing the work to a reasonable amount. So, let's write a thread pool.

It's easy to think that threads in Smalltalk are "free" - they are green threads, so what the heck - let's use more! However, you will (as Ramon writes) eventually hit a wall. I ran into one in BottomFeeder years ago, for slightly different reasons.

In BottomFeeder, I fork a Smalltalk process for each http request during an update loop. I subscribe to over 200 feeds, so that can amount to a lot of threads simultaneously clamoring for bandwidth. On my (fast) home connection, this was never a problem. However, back in the early 2000's, I was still running into dialup on the road at times, and even now, I periodically run into very slow Wifi. On slow connections, forking off that many processes just hurts more than it helps - so I wrote a thread pool into Bf.

What I should have done is what Ramon did - write a more general solution instead of burying it inside an app. However, it does show that this is something you might need, especially in the modern world of frequently (or always) connected apps.

Technorati Tags: ,

posted by James Robertson

 Share Tweet This