Must restart Apache when any .pm changes?

2001-04-22 Thread Steve Leibel

I'm experimenting with using Perl modules (.pm files) underneath 
Mason components.

As far as I can see, the only way to guarantee that changes made in 
the .pm are seen by the Mason code is to restart Apache whever the 
.pm file changes.  This is true whether the "use" statement is in 
handler.pl or in the component.

I believe the way this works is that the first time any Apache child 
process sees "use Foo" that is the version of Foo.pm that will be 
used by that process.  No subsequent "use Foo" within components will 
have any effect during the life of that Apache process.

Am I understanding this correctly?



Re: Shared memory between child processes

2001-03-30 Thread Steve Leibel

At 5:30 PM -0800 3/30/01, Randy J. Ray wrote:
I understand the forking model of Apache, and what that means in terms of
data initialized in the start-up phase being ready-to-go in each child
process. But what I need to do is manage it so that a particular value is
shared between all children, such that changes made by one are recognized
by the others. In a simple case, imagine wanting to count how many times
total the given handler is invoked. Bumping a global counter will still be
local to the given child process, and if part of the handler's interface is
to report this counter value, then the reported number is going to be
dependent upon which child answers the request.

I'm needing to implement a handler that uses a true Singleton pattern for
the class instance. One per server, not just one per process (or thread).



You'll need to use some form of persistance mechanism such as a 
database, file, or perhaps (assuming you're on a Unix system) 
something like System V shared memory or semaphores.

One quick 'n cheap way to implement mutual exclusion between Unix 
processes (executing on the same processor) is to use mkdir, which is 
atomic (ie once a process requests a mkdir, the mkdir will either be 
done or rejected before the requesting process is preempted by any 
other process).

So you can do

mkdir "xyz"
if "xyz" already exists, wait or return an error
read or write shared variable on disc
rmdir "xyz"

to guarantee that only one process at a time can be trying to access 
a disc file.

There are many possible variations on this theme.




Re: Perl incompat. with apache/mod_perl upgrade

2001-03-12 Thread Steve Leibel

At 12:26 PM -0500 3/12/01, Khachaturov, Vassilii wrote:
When I upgraded from
Solaris Apache/1.3.14 (Unix) mod_perl/1.24_01
to
Solaris Apache/1.3.17 (Unix) mod_perl/1.25

the following code in my debugging httpd.conf broke:

Perl
sub WWW_DIR () { $ENV{'HOME'} . '/www' ; } # this sub will persist to next
Perl
... more code, using WWW_DIR sometimes
/Perl


When I built Apache 1.3.17 with mod_perl 1.2.5 and numerous other 
mods, the resulting httpd was unable to read its usual configuration 
file.  When I upgraded to Apache 1.3.19 the problem went away.

I'd try 1.3.19.