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: AS33070 50.56.128.0/17 X-Spam-Status: No, score=0.0 required=3.0 tests=AWL,MSGID_FROM_MTA_HEADER, TVD_RCVD_IP shortcircuit=no autolearn=unavailable version=3.3.2 Path: news.gmane.org!not-for-mail From: "Lin Jen-Shin (godfat)" Newsgroups: gmane.comp.lang.ruby.rainbows.general Subject: Re: negative timeout in Rainbows::Fiber::Base Date: Thu, 30 Aug 2012 00:00:46 +0800 Message-ID: References: <20120825024556.GA25977@dcvr.yhbt.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1346256589 25250 80.91.229.3 (29 Aug 2012 16:09:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Aug 2012 16:09:49 +0000 (UTC) To: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Original-X-From: rainbows-talk-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Wed Aug 29 18:09:47 2012 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 X-Greylist: delayed 498 seconds by postgrey-1.31 at rubyforge; Wed, 29 Aug 2012 16:09:36 UTC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=godfat.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=cSyJY1Mrna9CQwLiLSSGoefrMu55hqddLf+6TLxqaWY=; b=E7QRiCh/tTTVSEk+7J7bv1UnMePXQU0r9ivasJxzIG3dP7QpT9rnMFsDZD6j87EKiX UB4FsxOzHd7IH57yLSkQyOkMAwJePN+VBtxVpLOsrh/vp+xRRYEs1U090mFk8qK60nwj GqhgDb/mS1RgaFzcYc7yH927vGoHv+Lw2CBCQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=cSyJY1Mrna9CQwLiLSSGoefrMu55hqddLf+6TLxqaWY=; b=mdBbNWV18KGaiSYllHLJCyjKfN4bF173sU0HoUWpVnkhvxYK7iVuJEv0giMMz76zMD VZM+c8jwXZ5RXC5p0kF/Xc5r7g+ZlD3h7CtoPlFwuPqhMqwO8g/WPYfoKhggYMEbkmsF eiZJFieay4my8BUCxsUGNkNRTUGIpeuNao6vGlzCEWBmf8QiVcDmPsxQhcS+Ja8Qodkt wavD6XJti4/5ajFQCV3Xn4CmEf4HMxBxBN0EA7frcGgDabllRw273N8xWzs31gmaMfop Pj5wMNFqz3g/MsoK1uZEKz25DGSDk7vKKdXQmF7zPyLXMTvHMLb5S5cpLDA+I7zB7YTk fPxg== In-Reply-To: X-Gm-Message-State: ALoCoQmcVggpXtN3/3i6sJs6TncvzLPFcJS1ib3PEurHad3WtncwYE3GxwxlS8z9Yj8t3bOjgmD1 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:398 Archived-At: Received: from 50-56-192-79.static.cloud-ips.com ([50.56.192.79] helo=rubyforge.org) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1T6kpu-0003Kp-Gh for gclrrg-rainbows-talk@m.gmane.org; Wed, 29 Aug 2012 18:09:46 +0200 Received: from localhost.localdomain (localhost [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id BD2862E068; Wed, 29 Aug 2012 16:09:42 +0000 (UTC) Received: from mail-lpp01m010-f50.google.com (mail-lpp01m010-f50.google.com [209.85.215.50]) by rubyforge.org (Postfix) with ESMTP id 83F782E05F for ; Wed, 29 Aug 2012 16:09:36 +0000 (UTC) Received: by lago2 with SMTP id o2so940194lag.23 for ; Wed, 29 Aug 2012 09:09:35 -0700 (PDT) Received: by 10.112.25.99 with SMTP id b3mr473713lbg.114.1346256077172; Wed, 29 Aug 2012 09:01:17 -0700 (PDT) Received: by 10.114.71.44 with HTTP; Wed, 29 Aug 2012 09:00:46 -0700 (PDT) Sorry that I didn't subscribe the mailing list (now subscribed), so I didn't realize there's already a response. The quoted text is copied from archive. Eric Wong wrote: > "Lin Jen-Shin (godfat)" wrote: > Yes. (Though it should've be easy to just pipe that part of my > message to "git apply" or even "patch -p1") I did that in the beginning, but it looks like your patch was not created from 12281e4cee86496588814cd1851e8764caea024c, so I cannot apply it? Anyway, not important :) > All the Thread-based concurrency models should already just work > with Celluloid-based apps. > http://news.gmane.org/find-root.php?message_id=%3cBANLkTimnNQYpk7TRkiCvhDikzGHVy%3dkOdw%40mail.gmail.com%3e And it's not worth the effort to wrap around celluloid-io for buffering requests? Since it's using nio4r[0] underneath and it's using libev for I/O, I thought that would be a replacement for eventmachine? [0]: https://github.com/tarcieri/nio4r > It's much easier to unwatch IO objects with Cool.io than with EM, so I > haven't done much with EM + Fibers. There's also rack-fiber_pool... True, working with Cool.io is much more pleasant. As for rack-fiber_pool, I am not sure if I am correct or not, but in my humble option, that's a totally wrong approach. I think fibers should be handled in server level, not application level. That way, we don't need the hack for throwing :async, and the middlewares do not need to be aware of fibers and :async, and we won't need async-rack, and the server doesn't need to be aware of :async, so on so forth. I am not sure if this approach would have any bad influence, but at least it works fine in our applications. That is, just wrap fibers around the calling the app. (i.e. Fiber.new{ app_call(env) }.resume) > Rainbows::EventMachine::TryDefer already uses the EM-internal thread > pool, so I think EventMachineThreadPool would be redundant. I didn't know this before, I guess it should work for me, though it might not be as direct as: https://github.com/godfat/ruby-server-exp/blob/9d44f8387739f5395bf97aff1689f17615cc4c7e/config/rainbows-em-thread-pool.rb#L21-25 class REMTPoolClient < Rainbows::EventMachine::Client def app_call input EM.defer{ super } end end > > https://github.com/cardinalblue/rest-more/blob/master/example/rainbows.rb#L15-19 > > class REMFClient < Rainbows::EventMachine::Client > > def app_call input > > Fiber.new{ super }.resume > > end > > end > Does it actually show benefits compared to regular EM? > I suppose the Rack application still needs to be made Fiber-aware > to reap benefits of Fibers The Rack application doesn't need to be fiber-aware, but if the libraries are fiber-aware, then it would be beneficial. The rest of program doesn't have to know the existence of fibers, because we don't throw :async. > Yes, threads are far more compatible with existing gems/libraries and I > think that's the better way to go. Of course, just processes (with > regular unicorn) should be most compatible, too. At first I thought fibers are better for I/O, but after implementing a thread based approach for the same mechanism, I started to doubt that. I don't have a conclusion yet though. (I am a bit nervous to switch to thread based approach on production to find out, since it's not yet tested intensively) On the other hand, all our apps are running on Heroku, and we need to reduce memory usage because they have a hard limit. That's why we're running Zbatery at the moment. > > Sorry that I might be asking too many questions in a single thread. > No problem! I'm just happy that folks are showing interest I really don't understand why Unicorn family didn't get much attention in Ruby community. And I always feel wrong when people are comparing Unicorn with Thin or even Passenger. (sigh) Many thanks for your work and help! _______________________________________________ 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