Rainbows and 2.0.0pre - thread safety
normalperson at yhbt.net
Mon Jun 20 17:29:39 EDT 2011
Kyle Drake <kyledrake at gmail.com> wrote:
> Hi guys,
> I've setup a load test for Rainbows with Rubinius 2.0.0pre:
> When I load test it on 2.0.0pre (via rvm and with apache bench), it
> has a lot of weird, random errors. My current hypothesis is this is a
> bug pertaining to thread safety in Rubinius, but someone suggested I
> post it here so you could take a look. Tried both ThreadSpawn and
> ThreadPool. I also made a test for Mongrel (which has similar errors),
> and Thin (which works fine, but doesn't really utilize threads so it
> doesn't mean anything).
Sounds likely Rubinius isn't 100% thread-safe. WEBrick should be worth
a try, too, since it's part of the standard library. I would start
Does calling C extensions in Rubinius 2.x take a global lock of any
sort? I seem to recall reading it did, but am not sure...
I also semi-recall reading that JRuby set the precedent for individual
Ruby methods on an object being thread-safe even with a free-threading
runtime, so stuff like:
thread 1 | thread 2
hash[:t1] = true | hash[:t2] = false
...wouldn't need locking for a given hash. It would be nice to confirm
if Rubinius follows that. I don't think the ThreadPool/ThreadSpawn
models rely on either of those behaviors, though.
> It would also be nice to know which deploy strategy would work well
> for Rubinius' threading. I wasn't sure if ThreadSpawn or ThreadPool
> made more sense so I tried both.
It probably depend more on your OS threading implementation and
hardware. Both are fully-supported and worth trying, though.
I use ThreadSpawn on my cheap VPS (bogomips.org/rainbows.git) since it's
memory-constrained, receives almost no traffic, and spawning threads
with NTPL is cheap vs my peak request rate.
ThreadPool might be better if you have a very high rate of requests
and/or spawning OS threads is expensive given your request rate.
Thanks for the interest in Rainbows!
More information about the rainbows-talk