Return-Path: Delivered-To: apmail-perl-modperl-archive@www.apache.org Received: (qmail 56337 invoked from network); 20 May 2010 15:17:58 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 20 May 2010 15:17:58 -0000 Received: (qmail 46176 invoked by uid 500); 20 May 2010 15:17:57 -0000 Delivered-To: apmail-perl-modperl-archive@perl.apache.org Received: (qmail 46145 invoked by uid 500); 20 May 2010 15:17:57 -0000 Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list modperl@perl.apache.org Received: (qmail 46138 invoked by uid 99); 20 May 2010 15:17:57 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 20 May 2010 15:17:57 +0000 X-ASF-Spam-Status: No, hits=2.5 required=10.0 tests=AWL,FREEMAIL_FROM,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of teknosoul@gmail.com designates 209.85.161.49 as permitted sender) Received: from [209.85.161.49] (HELO mail-fx0-f49.google.com) (209.85.161.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 20 May 2010 15:17:52 +0000 Received: by fxm15 with SMTP id 15so137167fxm.22 for ; Thu, 20 May 2010 08:17:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=D/NrVFEWQwFyc88PLVV5EffG/Cydq/Vokd0ps6JflSY=; b=b0apzlrmxEuiCAXys6VXPNI1t3OqTbRZzadQhPWPn2Q89lNTqZXrZuDXi8hq1vHJh5 FyqNveuZbJ4199DyzSAykb7GRGLGLEACsxVNLEGXxoc9f0RSoHQZJnXWAV/ikPHAmvha lIdOGJQ0oEjcAb4JNRiSMuPOwAQY6DZN7Stu8= 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 :cc:content-type; b=eT01c7MeVypfa52X5Y9dK8btZZlKxVEjWMQ6/D6D+kM6kcDIJflRLwfWN7bj3E4LmZ sIXrZNVsvGZyo8ZfzqrUU+qrjMEqu7i86xb2Tu7u/GS8jk/9Tz7oIRcrIfauPux8a6Zt 750HWbCaG6d2HURPZMVmZk9VD/83UPTlaDpTs= MIME-Version: 1.0 Received: by 10.239.174.70 with SMTP id i6mr18576hbf.180.1274368650355; Thu, 20 May 2010 08:17:30 -0700 (PDT) Received: by 10.239.148.196 with HTTP; Thu, 20 May 2010 08:17:30 -0700 (PDT) In-Reply-To: References: <4BF53735.6030001@plusthree.com> Date: Thu, 20 May 2010 11:17:30 -0400 Message-ID: Subject: Re: PerlModule lifetime / threads From: Some Guy To: Michael Peters Cc: Perrin Harkins , modperl@perl.apache.org Content-Type: multipart/alternative; boundary=0016363b9f2ab7a5b8048708121e --0016363b9f2ab7a5b8048708121e Content-Type: text/plain; charset=ISO-8859-1 I tried the cleanup handler solution, and threw a sleep in there for ha has. Basically I do the following in my handler: Register a cleanup on the request's pool Check if I need to do something to the user agent if it is found in an array that is backed by a data file If it's not in the array, decline the request, else, do my thing. In the cleanup: Check if the file has changed since i last checked Reload the file into the array if necessary If the MPM is threaded, a rwlock is used where the cleanup obtains the writelock and request handlers are obtaining a read lock. I threw a sleep in the cleanup to see what happens, and it appears to delay sending the results of the next request. I issued a request, then issued another. I didn't get the results of the second request until the sleep from the first returned. No locks used by the request handler are held during sleep time, and the MPM is threaded. I had expected the request to be flushed to the client before the cleanup code is run. Is this wrong? Thanks, SB On Thu, May 20, 2010 at 9:58 AM, Some Guy wrote: > This module is meant for other parties to use, so I can't define what MPM > they use. I would like it to work in either case. I don't mind throwing in > locking logic based on the results of querying whether the MPM is threaded > or not - I just want to better understand that scenario and how it applies > to modules written for mod_perl. > > Thanks, > > SB > On Thu, May 20, 2010 at 9:20 AM, Michael Peters wrote: > >> On 05/20/2010 08:54 AM, Some Guy wrote: >> >>> The cleanup handler is a brilliant idea. That removes the need for a >>> polling thread. If I attach the cleanup to the request's pool and run >>> in a threaded MPM, this led to contention for the globals that I'm >>> updating in C. Is this the case with PerlModules, or can I get away >>> without locking them? >>> >> >> Why use a threaded MPM? Is there something else you're running that relies >> on it? We generally recommend doing with the prefork mpm because you're >> running in share-nothing mode which performs better (and uses less memory on >> decent operating systems). >> >> -- >> Michael Peters >> Plus Three, LP >> > > --0016363b9f2ab7a5b8048708121e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I tried the cleanup handler solution, and threw a sleep in there for h= a has.=A0 Basically I do the following in my handler:
=A0
Register a cleanup on the request's pool
Check if I need to do something to the user agent if it is found in an= array that is backed by a data file
If it's not in the array, decline the request, else, do my thing.<= br>
In the cleanup:
Check if the file has changed since i last checked
Reload the file into the array if necessary
=A0
If the MPM is threaded, a rwlock is used where the cleanup obtains the= writelock and request handlers are obtaining a read lock.
=A0
I threw a sleep in the cleanup to see what happens, and it appears to = delay sending the results of the next request.=A0 I issued a request, then = issued another.=A0 I didn't get the results of the second request until= the sleep from the first returned.=A0 No locks used by the request handler= are held during sleep time, and the MPM is threaded.=A0 I had expected the= request to be flushed to the client before the cleanup code is run.=A0 Is = this wrong?
=A0
Thanks,
=A0
SB
=A0
On Thu, May 20, 2010 at 9:58 AM, Some Guy <teknosoul@gmail.com<= /a>> wrote:
This module is meant for other parties to use, so I can't define w= hat MPM they use.=A0 I would like it to work in either case.=A0 I don't= mind throwing in locking logic based on the results of querying whether th= e MPM is threaded or not - I just want to better understand that scenario a= nd how it applies to modules written for mod_perl.
=A0
Thanks,
=A0
SB
On Thu, May 20, 2010 at 9:20 AM, Michael Peters = <mpeters@plusthree.com> wrote:
On 05/20/2010 08:54 AM, Some Guy wrote:
The cleanup handler is a brillia= nt idea. =A0That removes the need for a
polling thread. =A0If I attach t= he cleanup to the request's pool and run
in a threaded MPM, this led to contention for the globals that I'm
u= pdating in C. =A0Is this the case with PerlModules, or can I get away
wi= thout locking them?

Why use a threaded MPM? Is th= ere something else you're running that relies on it? We generally recom= mend doing with the prefork mpm because you're running in share-nothing= mode which performs better (and uses less memory on decent operating syste= ms).

--
Michael Peters
Plus Three, LP


--0016363b9f2ab7a5b8048708121e--