Michael Peters wrote:
André Warnier wrote:
My doubts focus (mainly) on the following issues
- wether or not I *can* declare and initialise some object e.g. in the
PerlChildInitHandler, and later access that same object in the request
handlers.
Yes.
- also, if later from the request handler, I would call a method of this
object that updates the object content, wether this updated object would
still be "shared" by all subsequent instances of request handlers.
That depends on whether or not you have a threaded mpm. Even OSes with COW won't
shared updated structures.
Ok, I'm already a bit out of my depth here.
Tell me if the following is correct :
1) Apache forking model (non-threaded) :
a) Apache starts and forks a number of children.
b) Each child executes its PerlChildInitHandler.
c) within each of these children, I thus now have an object containing
the initial version of the hashtable I loaded.
Let's say that this "hashtable+ object" is accessible via the global
identifier $OBJ. Each child has its own $OBJ.
d) requests are processed each by a child. There can be several
simultaneous requests being processed, but there is only one request
(and one mp2 content handler) being executed at anyone time within each
child process. This handler "instance" has access to the $OBJ object of
its own parent child.
e) if one handler instance somehow modifies the content of the $OBJ
object, then it is (only) this Apache child's version of $OBJ that is
modified.
f) if a new request happens to be processed again by this same child,
the content handler instance that runs then, will see the $OBJ as
(possibly) modified by the previous request processed in that child.
g) there is no real need to "lock" the $OBJ while it's being modified,
but it doesn't hurt either.
2) Apache running under a threaded MPM :
(basically all of this below is post-fixed with question marks, as I am
really very naive about threads. Be kind..)
a) Apache pre-forks at least one child (I think).
b) Each child executes its PerlChildInitHandler.
c) within each of these children, I thus now have an object containing
the initial version of the hashtable I loaded.
Let's say that this "hashtable+ object" is accessible via the global
identifier $OBJ.
d) each child (or the one child) launches a number of threads ???
(or are threads launched as requests come in ?)
e) each of these threads sees the *same* $OBJ (meaning at the same
memory location, not just a copy) ???
f) when a request comes in, it is handed off to a thread, which runs the
mp2 handler.
g) if this handler, by calling a method of $OBJ modifies $OBJ, what
happens ? does this particular thread now have its own private copy of
$OBJ ?
h) assuming that when a thread modifies $OBJ, it does so under
protection of some lock mechanism (I guess by defining the modifying
method as "locking"), does it matter ?
i) does a thread "stay alive" and handle possibly other subsequent
requests, or does one thread only handle one request and then die ?
Maybe I'll finally end up understanding threads.
Some hope.
3) (just looking for a yes or no here) : If I want to have only one
single copy of the hashtable in memory at any time, then the only
multi-platform and portable way is to offload the table and it's update
to a separate daemon, to which the various Apache processes would
address their translation requests (via TCP e.g.) . But then that one
process becomes the bottleneck, unless it's itself forking or
multi-threaded.
[...]
'lock' should be a no-op in recent versions of Perl that are non-threaded. So if
you have a non-threaded Perl running in a non-threaded mpm it should be ok. I've
never done it so you might want to check with others or ask on Perl monks.
Am I right to assume that if I have Apache2 and mod_perl2 and perl 5.8.x
installed (and apparently working well) on a given host, if Apache2 is
running with a threaded MPM, the perl version will also be
thread-enabled ? (or else I have a configuration problem)
And that if the Apache is running a non-threaded MPM, the perl that is
installed may well be a thread-enabled one, but the mp2 modules running
under it will never actually use threads ?
Later, I'll come with the "then how do I create this global object"
question..
