Re: shared memory

[prev] [thread] [next] [Date index for 2005/03/15]

He's my naive understanding of your concerns, someone here may have to=20=

correct me:

On Mar 15, 2005, at 6:26 PM, Andr=E9 Warnier wrote:
> I have previously gone though a lot of perl and mod_perl=20
> documentation, and perl module descriptions, and I never seemed to=20
> find a clear answer about wether yes or no it was possible to share=20
> in-memory data between 2 perl processes (or threads) running under=20
> Apache.
It's not.  Its part of the forking model and design.  That's why people=20=

suggested the use of DBs and caching systems such as memcached -- you=20
can store your data into a foreign object -- either a db or a memory=20
agent -- and then let separate processes or machines access it. =20
Anything you want to do can easily be handled by either a memory cache=20=

or a db cache.

>  How come no-one has come up yet with some scheme to "hijack" one of=20=

> these bucket brigades (or some other internal Apache memory area) to=20=

> provide such a capability ?
it sounds like you want to defeat the design of the forking model --=20
something like what you want would be more of a standalone daemon, and=20=

not Apache.

> Also, for instance, the DBI module and it's companion Apache::DBI=20
> provide persistent connections to databases. And to my knowledge, they=20=

> are available under Unix as well as Windows.  For doing this, there=20
> must be some form of memory sharing at work, isn't it so ?
If you instantiate a DBI handle before the fork, then that handle is=20
shared to all the children.  If you instantiate the handle after the=20
fork, the handle belongs to only that child , and shared across the=20
requests of that child.  So, if you get a handle, then spawn 12=20
children, they will each share the single handle.  If your code creates=20=

a handle after the fork, then you will have 12 handles.  There's a=20
section on 'shared memory' in both mod_perl books that explains it=20
better than my attempt -- there's also a section on using startup=20
scripts to preload all the info.

At first, the forking model is strange, its aggravating, and sometimes=20=

I wanted to kick it =96 it took a while for me to get used to it, and =
see=20
why it makes sense.  I still wish there were some ways to easier share=20=

data between children (maybe there are, and I no one on this list has=20
answered my hopes yet) -- but I've found using a db pretty damn good --=20=

and memcached supports sharing data between machines too.