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. > - supposing that this architecture is running within a threaded > environment, are there special guidelines to follow regarding the > possibility that 2 threads in the same child would access the object at > the same time and try to update the internal table ? Yes. It's a shared memory structure so you will need to use care to make sure it's not corrupted. See the 'lock' keyword. > - and if I follow such guidelines, does the same code also work if it > happens to run in a non-threaded environment ? '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. > - if there is a mandatory difference between threaded/non-threaded mp2 > perl code, can I check at run-time under which environment I'm running, > and condition which code is executed accordingly ? Jim already gave you a good answer here. -- Michael Peters Developer Plus Three, LP
