From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS14383 205.234.109.0/24 X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,FREEMAIL_FROM, MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD,T_DKIM_INVALID shortcircuit=no autolearn=unavailable version=3.3.2 Path: news.gmane.org!not-for-mail From: Jimmy Soho Newsgroups: gmane.comp.lang.ruby.unicorn.general Subject: Re: Thread.current Date: Wed, 12 Jan 2011 14:07:38 +1100 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1294802008 5742 80.91.229.12 (12 Jan 2011 03:13:28 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 12 Jan 2011 03:13:28 +0000 (UTC) To: unicorn list Original-X-From: mongrel-unicorn-bounces@rubyforge.org Wed Jan 12 04:13:24 2011 Return-path: Envelope-to: gclrug-mongrel-unicorn@m.gmane.org X-Original-To: mongrel-unicorn@rubyforge.org Delivered-To: mongrel-unicorn@rubyforge.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=fK7MtQ8M0viP8YhwfhCYfqVx2TlYt7dR4Tubasx4XOc=; b=Vl+kNw7vnc46e5h43QMSvXm/5MqDnzUjPn4SJ/ef85BRbG7u/Yb885YwW4vGxCcMz5 1mbPp2KSRdE68JfyapGDs3H/aiHvpFR6XMOu5UrapmKgXZCkDhEZSWfbowPwZ95hcfhs aXuiqt5AzzDGQ232E4+F1vEp+T4UjGhwcVzTI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Y/RnGiVR6qBTjnVk/Lemb1uKodko+sjWwYrAVLCle1kRM6zoOhs1iuC0R0TCUaRWCf oainhE+TAf6kXVCbOk4wuin78Rzyi8+6HQoMma1APV73XnMrhvaJMTweLWP6bVKOxOwQ nSf1sDz3eKkvRllkXY3a4ei5CFE/Iyq4XfC5U= In-Reply-To: X-BeenThere: mongrel-unicorn@rubyforge.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: mongrel-unicorn-bounces@rubyforge.org Errors-To: mongrel-unicorn-bounces@rubyforge.org Xref: news.gmane.org gmane.comp.lang.ruby.unicorn.general:816 Archived-At: Received: from rubyforge.org ([205.234.109.19]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Pcr9H-0004tt-3g for gclrug-mongrel-unicorn@m.gmane.org; Wed, 12 Jan 2011 04:13:23 +0100 Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 2BB51185836C; Tue, 11 Jan 2011 22:13:22 -0500 (EST) Received: from mail-qw0-f50.google.com (mail-qw0-f50.google.com [209.85.216.50]) by rubyforge.org (Postfix) with ESMTP id D5BAF1858367 for ; Tue, 11 Jan 2011 22:07:38 -0500 (EST) Received: by qwd6 with SMTP id 6so121997qwd.23 for ; Tue, 11 Jan 2011 19:07:38 -0800 (PST) Received: by 10.229.242.77 with SMTP id lh13mr335313qcb.194.1294801658550; Tue, 11 Jan 2011 19:07:38 -0800 (PST) Received: by 10.229.216.148 with HTTP; Tue, 11 Jan 2011 19:07:38 -0800 (PST) Some component don't always have to work within a webserver context, and therefor assume no access to a Rack +env+ hash. Widely used examples are the i18n and the active_support gem. In our case we have for example queued jobs that are executed with the full rails environment loaded, which does not have a rack context. This is not an issue, but does explain (to some extent) why some components use thread local storage instead of the rack +env+ context. I'm not trying to use Thread local storage myself, it is forced upon us. ;-) I'm trying to determine if the components we must use due to dependencies, and which do use Thread local storage, if they are leaking data from one request into the next request if you are within a unicorn context. There are cases where we want this, and there are cases where we don't want this leakage. Take for example activesupport's usage of Time.zone. Under water this is set in a thread local var. If you set Time.zone in one request, but not in the next request, using unicorn the next request will use the time zone of the previous request. Using rack or mongrel (in multithreaded mode) you don't have this issue perse (though they have other issues then). Same for the i18n gem and it's usage of the I18n.locale value, which is also set in a thread local var. So yeah, unfortunately I have to take into account this "crappy idiom" and need to know exactly which thread local vars are set by all the components we use, and determine which of those must be reset before each request. Cheers, Jimmy On Wed, Jan 12, 2011 at 10:12 AM, Jordan Ritter wrote: > Unicorn is purely about employing a multi-process model, not a multi-thre= ad model; it specifically avoids spawning threads to handle inbound request= s. =A0 In fact, I'll bet that inside each request, Thread.current =3D=3D Th= read.main. > > Separate from Unicorn, when running a rack-compatilbe app in multithreade= d 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. = =A0This 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 i= n either unicorn or multithreaded situations, so long as you wiped your sto= rage at the beginning/end of each request -- but that's a crappy idiom, eve= n if it might be "common" (don't know what you're referring to offhand). = =A0Can'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? =A0(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 > _______________________________________________ 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