Re: Thread.current

[Jordan Ritter <jpr5@darkridge.com>]

Unicorn is purely about employing a multi-process model, not a multi-thread model; it specifically avoids spawning threads to handle inbound requests.   In fact, I'll bet that inside each request, Thread.current == Thread.main.

Separate from Unicorn, when running a rack-compatilbe app in multithreaded mode (the default when the app is invoked directly via rackup + config.ru), there's no guarantee about which thread will service a given request.  This fact may not matter to you, depending on what you're trying to do.

That said, you *could* use Thread local storage for per-request storage in either unicorn or multithreaded situations, so long as you wiped your storage at the beginning/end of each request -- but that's a crappy idiom, even if it might be "common" (don't know what you're referring to offhand).  Can't suggest a more appropriate pattern without knowing more about what you're actually trying to do.

cheers,
--jordan

On Jan 11, 2011, at 2:52 PM, Jimmy Soho wrote:

> Hi,
> 
> Some more questions still:
> 
> It seems a worker uses the exact same thread to handle each request.
> 
> Is that guaranteed to happen for the lifetime of a worker? Or are
> there cases where a unicorn worker might spin a new thread to handle
> the next requests?
> 
> If the same thread is always used, isn't that a potential issue when
> programmers use thread local variables, which are not reset at the
> next request?  (I know, the usage of thread local variables is not
> recommended, but take a random rails project, go into their $GEM_HOME
> and do grep -r Thread.current . , see what I mean..)
> 

_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying