negative timeout in Rainbows::Fiber::Base

Lin Jen-Shin (godfat) godfat at
Wed Aug 29 16:00:46 UTC 2012

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 <normalperson at> wrote:
> "Lin Jen-Shin (godfat)" <godfat at> 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.

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?


> It's much easier to unwatch IO objects with than with EM, so I
> haven't done much with EM + Fibers.  There's also rack-fiber_pool...

True, working with 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.{ 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:
  class REMTPoolClient < Rainbows::EventMachine::Client
    def app_call input
      EM.defer{ super }

> >
> > class REMFClient < Rainbows::EventMachine::Client
> >   def app_call input
> >{ 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.

Many thanks for your work and help!

More information about the rainbows-talk mailing list