[Seaside] Concurrency question
Smalltalk at JGFoster.net
Sun Feb 17 20:13:30 UTC 2008
Welcome to Seaside!
You are right that most implementations of Smalltalk are single-
threaded. There is, however, a built-in process scheduler ("green
threads") that allows code to be forked. If your long-running request
is compute bound and you reduce its priority or yield periodically
then other requests should be handled. If your long-running request is
waiting on an external resource (the typical example is credit card
verification), you might be able to code things so that that
particular request is in a separate OS thread or takes advantage of a
non-blocking socket wait. I believe that these comments apply to
Squeak's implementation of Seaside (and possibly the VW implementation
In GemStone each VM is also single-threaded but you can have multiple
VMs attached to the same object space. Here the typical approach is to
use Apache to round-robin requests to separate VMs so that blocking is
less of an issue. See http://seaside.gemstone.com and http://gemstonesoup.wordpress.com
for more info.
On Feb 17, 2008, at 12:00 PM, Jeffrey Straszheim wrote:
> Howdy folks,
> I'm currently evaluating Seaside for a project and have a question.
> How does it handle concurrent connections? I understand that the
> underlying Squeak VM does not use OS threading, and so the system
> does not take advantage of SMP. That is OK with me. However, I'm
> curious if Seaside will still be able to handle the situation where
> we get one or more LONG http requests. Will these cause undo lag to
> other users trying to connect.
> To give some background for my concern, I've been using Rails, which
> is strictly single threaded, so a long response to a single request
> can cause other users to be blocked out from that rails instance.
> I'm hoping Seaside will not have this problem.
> Thanks in advance,
> Jeffrey Straszheim
> seaside mailing list
> seaside at lists.squeakfoundation.org
More information about the seaside