Rainbows! Rack HTTP server user/dev discussion
 help / color / mirror / code / Atom feed
From: Eric Wong <normalperson-rMlxZR9MS24@public.gmane.org>
To: Rainbows! list <rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org>
Subject: Re: negative timeout in Rainbows::Fiber::Base
Date: Sun, 26 Aug 2012 01:15:02 +0000	[thread overview]
Message-ID: <20120826011502.GC32346@dcvr.yhbt.net> (raw)
In-Reply-To: <CAA2_N1uhfcHDbTvY+ke0Cid6=i7KEhFn8jvEirx+ptYVDacdvA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

"Lin Jen-Shin (godfat)" <godfat-hOE/xeEBYYIdnm+yROfE0A@public.gmane.org> wrote:
> On Sat, Aug 25, 2012 at 10:45 AM, Eric Wong <normalperson-rMlxZR9MS24@public.gmane.org> 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.


> 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.

Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
Do not quote signatures (like this one) or top post when replying

  parent reply	other threads:[~2012-08-26  1:19 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-23 20:36 negative timeout in Rainbows::Fiber::Base Lin Jen-Shin (godfat)
     [not found] ` <CAA2_N1unOXb7Z4Jr8oKoSLu266O9Ko4o=oWzAcMA1w3=9X74KA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-08-25  2:45   ` Eric Wong
     [not found]     ` <20120825024556.GA25977-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>
2012-08-26  0:12       ` Lin Jen-Shin (godfat)
     [not found]         ` <CAA2_N1uhfcHDbTvY+ke0Cid6=i7KEhFn8jvEirx+ptYVDacdvA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-08-26  1:15           ` Eric Wong [this message]
2012-08-29 16:00           ` Lin Jen-Shin (godfat)
     [not found]             ` <CAA2_N1thakAOVp7ibCNic+TjEVvXE0OGLgzXH3fJ1c2UTs68oQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-08-29 21:17               ` Eric Wong
     [not found]                 ` <20120829211707.GA22726-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>
2012-08-30 21:33                   ` Lin Jen-Shin (godfat)
     [not found]                     ` <CAA2_N1tc=Xx8WHaM8H=EWshyzGEyX04PnkdBGj9Jdb7cSzmbRQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-08-31  1:37                       ` Eric Wong
     [not found]                         ` <20120831013731.GA16613-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>
2012-09-05 20:06                           ` Lin Jen-Shin (godfat)
     [not found]                             ` <CAA2_N1vfWXGw_CaaMWMijUSdMN2Pz882SYDtNEW2_6YWffgTKQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-09-05 23:27                               ` Eric Wong
     [not found]                                 ` <20120905232739.GA25153-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>
2012-09-22  9:52                                   ` Lin Jen-Shin (godfat)
     [not found]                                     ` <CAA2_N1v460utbL31Qu-JbGuUxav1hY4X5+cEf=Mp2rOC5efzMw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-09-22 19:42                                       ` Eric Wong
     [not found]                                         ` <20120922194222.GA6839-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>
2012-09-28 15:14                                           ` Lin Jen-Shin (godfat)
     [not found]                                             ` <CAA2_N1usHJVZgn5n7RaTyDCbK7eu6G4ocZAsvqsVeL6cPERskw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-09-28 19:11                                               ` Eric Wong
     [not found]                                                 ` <20120928191132.GA14292-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>
2012-09-28 19:24                                                   ` Eric Wong
     [not found]                                                     ` <20120928192449.GB14292-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>
2012-10-31  0:14                                                       ` Lin Jen-Shin (godfat)
2012-12-18 11:09                                                       ` Lin Jen-Shin (godfat)
     [not found]                                                         ` <CAA2_N1tcA-HK20C8Ok1Lv9KWwMD4fctCOPHTLeD9ayRJqWby1Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-12-18 19:19                                                           ` Eric Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://yhbt.net/rainbows/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120826011502.GC32346@dcvr.yhbt.net \
    --to=normalperson-rmlxzr9ms24@public.gmane.org \
    --cc=rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).