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

Reply via email to