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 - [email protected] http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
