perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Some Guy <>
Subject Re: PerlModule lifetime / threads
Date Thu, 20 May 2010 15:17:30 GMT
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?



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

View raw message