From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on dcvr.yhbt.net X-Spam-Level: * X-Spam-ASN: AS14383 205.234.109.0/24 X-Spam-Status: No, score=1.0 required=3.0 tests=AWL,HK_RANDOM_FROM, MSGID_FROM_MTA_HEADER shortcircuit=no autolearn=no version=3.3.2 Path: news.gmane.org!not-for-mail From: Eric Wong Newsgroups: gmane.comp.lang.ruby.rainbows.general Subject: Re: Rainbows and 2.0.0pre - thread safety Date: Mon, 20 Jun 2011 14:29:39 -0700 Message-ID: <20110620212939.GA18538@dcvr.yhbt.net> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1308605464 30965 80.91.229.12 (20 Jun 2011 21:31:04 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 20 Jun 2011 21:31:04 +0000 (UTC) To: Rainbows! list Original-X-From: rainbows-talk-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Mon Jun 20 23:30:59 2011 Return-path: Envelope-to: gclrrg-rainbows-talk@m.gmane.org X-Original-To: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Delivered-To: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: rainbows-talk-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Errors-To: rainbows-talk-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Xref: news.gmane.org gmane.comp.lang.ruby.rainbows.general:265 Archived-At: Received: from rubyforge.org ([205.234.109.19]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QYm3Z-0005Uv-7y for gclrrg-rainbows-talk@m.gmane.org; Mon, 20 Jun 2011 23:30:53 +0200 Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id AB37A1858361; Mon, 20 Jun 2011 17:30:52 -0400 (EDT) Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by rubyforge.org (Postfix) with ESMTP id A47501858361 for ; Mon, 20 Jun 2011 17:29:39 -0400 (EDT) Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 493231F84D; Mon, 20 Jun 2011 21:29:39 +0000 (UTC) Kyle Drake wrote: > Hi guys, > > I've setup a load test for Rainbows with Rubinius 2.0.0pre: > > https://github.com/kyledrake/rubinius-sinatra-loadtesting/tree/master/rainbows > > 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 there, actually. Some questions: 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. > Cheers! Thanks for the interest in Rainbows! -- Eric Wong _______________________________________________ Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org http://rubyforge.org/mailman/listinfo/rainbows-talk Do not quote signatures (like this one) or top post when replying