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: [PATCH] possible MRI 1.8 thread fix to avoid blocking accept() Date: Mon, 21 Dec 2009 16:54:21 -0800 Message-ID: <20091222005421.GA23044@dcvr.yhbt.net> References: <20091221221002.GA12277@dcvr.yhbt.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1261443270 13933 80.91.229.12 (22 Dec 2009 00:54:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Dec 2009 00:54:30 +0000 (UTC) To: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Original-X-From: rainbows-talk-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Tue Dec 22 01:54:23 2009 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: <20091221221002.GA12277-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org> User-Agent: Mutt/1.5.18 (2008-05-17) 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:53 Archived-At: Received: from rubyforge.org ([205.234.109.19]) by lo.gmane.org with esmtp (Exim 4.50) id 1NMt14-0001XV-W9 for gclrrg-rainbows-talk@m.gmane.org; Tue, 22 Dec 2009 01:54:23 +0100 Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id E712818582BF; Mon, 21 Dec 2009 19:54:22 -0500 (EST) Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by rubyforge.org (Postfix) with ESMTP id B9B5518582BF for ; Mon, 21 Dec 2009 19:54:21 -0500 (EST) Received: from localhost (unknown [127.0.2.5]) by dcvr.yhbt.net (Postfix) with ESMTP id 3662C1F525; Tue, 22 Dec 2009 00:54:21 +0000 (UTC) Under MRI 1.8, listen sockets do not appear to have the nonblocking I/O flag on by default, nor does it set the nonblocking I/O flag when calling #accept (but it does when using #accept_nonblock, of course). Normally this is not a problem even when using green threads since MRI will internally select(2) on the file descriptor before attempting a blocking (and immediately successful) accept(2). However, when sharing a listen descriptor across multiple processes, spurious wakeups are likely to occur, causing multiple processes may be woken up when a single client connects. This causes a problem because accept(2)-ing on multiple threads/processes for a single connection causes blocking accepts in multiple processes, leading to stalled green threads. This is not an issue under 1.9 where a blocking accept() call unlocks the GVL to let other threads run. --- I just pushed this out to git://git.bogomips.org/rainbows.git, too. Testers appreciated, thanks. Eric Wong wrote: > I've heard (privately) about issues with accept() somehow blocking the > entire worker process under 1.8. Obviously this really should not > happen, but I'm unable to reproduce it myself. lib/rainbows/base.rb | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/lib/rainbows/base.rb b/lib/rainbows/base.rb index 211b41c..4a4d076 100644 --- a/lib/rainbows/base.rb +++ b/lib/rainbows/base.rb @@ -14,6 +14,12 @@ module Rainbows super(worker) G.tmp = worker.tmp + # avoid spurious wakeups and blocking-accept() with 1.8 green threads + if RUBY_VERSION.to_f < 1.8 + require "io/nonblock" + LISTENERS.each { |l| l.nonblock = true } + end + # we're don't use the self-pipe mechanism in the Rainbows! worker # since we don't defer reopening logs HttpServer::SELF_PIPE.each { |x| x.close }.clear -- 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