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=1.0 required=3.0 tests=AWL,HK_RANDOM_FROM, MSGID_FROM_MTA_HEADER,TVD_RCVD_IP 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: negative timeout in Rainbows::Fiber::Base Date: Sun, 26 Aug 2012 01:15:02 +0000 Message-ID: <20120826011502.GC32346@dcvr.yhbt.net> 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 1345943969 13451 80.91.229.3 (26 Aug 2012 01:19:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 26 Aug 2012 01:19:29 +0000 (UTC) To: Rainbows! list Original-X-From: rainbows-talk-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Sun Aug 26 03:19:27 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 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) 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:397 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 1T5RVe-0003lW-RU for gclrrg-rainbows-talk@m.gmane.org; Sun, 26 Aug 2012 03:19:27 +0200 Received: from localhost.localdomain (localhost [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 518342E062; Sun, 26 Aug 2012 01:19:24 +0000 (UTC) Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by rubyforge.org (Postfix) with ESMTP id CBF692E05D for ; Sun, 26 Aug 2012 01:15:03 +0000 (UTC) Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id E5C871F520; Sun, 26 Aug 2012 01:15:02 +0000 (UTC) "Lin Jen-Shin (godfat)" wrote: > On Sat, Aug 25, 2012 at 10:45 AM, Eric Wong wrote: > > The original code looks wrong and confusing :x > > I guess I know your intension in the new code now :) > I can't apply the new patch, so I'll assume the new > code is as following: > > fibs.each { |fib| fib.resume } > > max_sleep = 1.0 > if max > max -= Time.now > return 0 if max < 0.0 > return max_sleep if max > max_sleep > max > else > max_sleep > end Yes. (Though it should've be easy to just pipe that part of my message to "git apply" or even "patch -p1") > I once thought that if `max < Time.now`, it should return 0, > because apparently we don't want to wait in this case. > But I am not sure if passing timeout as 0 would mean to > wait forever... thinking that maybe 0.0001 might be better? > Not sure if this would be a concern, or 0 means don't wait > at all, that would be ideal in this case. Aa timeout of 0 returns immediately for select (and poll/epoll/kevent), but still marks ready descriptors. > > It's been a while since I've looked hard at the Fiber* stuff (not a fan > > of it personally). However, I don't think abs() is correct, either. > > I can smell from the code that those are not well polished, > since it seems a lot of things are missing. For example, > there is Rainbows::Fiber::IO::Socket, but no TCPSocket. > I blindly tried to create a TCPSocket version by creating > a new class extended from Kgio::TCPSocket and include > Rainbows::Fiber::IO::Methods. Yeah, it was an experiment and I've become less-interested in Fibers over time. > Well, I think it works, if using correctly, for example it > does not accept domain names as built-in TCPSocket, > and not all of the methods are respecting fibers. DNS resolution needs to be handled asynchronously as well, so I'd rather leave it out than block on the portable DNS lookup functions. > But I like the idea to patch the socket, that way, we can > turn existing library to run under certain network architecture. > For instance, this HTTP client accepts passing different > socket class: > https://github.com/tarcieri/http/blob/master/lib/http/options.rb#L33-37 > > @default_socket_class = TCPSocket > @default_ssl_socket_class = OpenSSL::SSL::SSLSocket > > class << self > attr_accessor :default_socket_class, :default_ssl_socket_class > > I didn't try if passing Rainbows' fiber sockets would work or not, > but I think in theory it should work. I think Tony did this for his: > https://github.com/celluloid/celluloid-io > Quoted from README: > > """ > Replacement classes: Celluloid::IO includes replacements for the core > TCPServer and TCPSocket classes which automatically use an evented > mode inside of Celluloid::IO actors. They're named > Celluloid::IO::TCPServer and Celluloid::IO::TCPSocket, so they're > automatically available inside your class when you include > Celluloid::IO. > """ > > Not sure if this is the way to go, but an interesting idea. At least > better than implementing every single client in both eventmachine > and built-in sockets I guess... > > So speaking to celluloid-io, there's already Revactor and Coolio > support, what about celluloid-io? Last time I tried Coolio, > occasionally it would crash with internal assertion failures... > I would love to see if there's other alternatives to eventmachine. 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 > Also, there is CoolioFiberSpawn, CoolioThreadPool and so on > so forth, why not EventMachineFiberSpawn and EventMachineThreadPool? 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... Rainbows::EventMachine::TryDefer already uses the EM-internal thread pool, so I think EventMachineThreadPool would be redundant. > Actually we are running EventMachineFiberSpawn on production > at the moment, as shown in: > > 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 > (well, neverblock works too, but it doesn't seem to be > maintained now and I don't understand why it's a gem > with a lot of codes but not as simple as above. As this > sense, I feel async_sinatra is so wrong, but not sure > if I missed something here.) > > It works great for us at the moment, though I am thinking about > switching to threads, too, since it's a lot more flexible than fibers. 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. > Sorry that I might be asking too many questions in a single thread. No problem! I'm just happy that folks are showing interest > If you're interested in how I am testing them, I put my testing codes > at: https://github.com/godfat/ruby-server-exp > I am thinking about if I should be giving a talk on rubyconf.tw > about ruby application servers, promoting unicorn family. > It is one of the reasons to try out all of the options. Cool! _______________________________________________ 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