Out of band stuff?

Eric Wong normalperson at yhbt.net
Tue Apr 10 20:37:43 UTC 2012

Damian Janowski <jano at dimaion.com> wrote:
> On Mon, Apr 9, 2012 at 12:05 AM, Eric Wong <normalperson at yhbt.net> wrote:
> >        # @start is a Mutex and @thr is nil in the initialize method.
> >
> >        @start.synchronize { @thr ||= aggregator_thread(env["rack.logger"]) }
> >
> > I avoid starting the background thread at initialization because it'll
> > die on fork (meaning I'd have to recheck it all the time, anyways).
> >
> > The overhead of Mutex#synchronize and @thr||= assignment is negligible
> > in most apps.
> One more question. Can you confirm that this technique doesn't work as
> expected using Rainbows/ThreadPool? I've found that Rack::Builder
> creates a new instance of each middleware on every request, so you'd
> end up spawning infinite aggregator threads.

Huh? How are you using Rack::Builder?  unicorn/Rainbows! should always be
using Rack::Builder#to_app instead of regenerating the Rack stack every
single request.

I've been using Raindrops::Watcher for months now, mainly with
ThreadSpawn, but ThreadPool seems to work just fine and I can confirm
neither spawns infinite aggregator threads.

More information about the rainbows-talk mailing list