Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

Re: Re: Sharing data structures among http processes?

by sutch (Curate)
on Jun 28, 2001 at 02:53 UTC ( #92109=note: print w/replies, xml ) Need Help??

in reply to Re: Sharing data structures among http processes?
in thread Sharing data structures among http processes?

Thanks tomhukins, this looks to be what is needed. And your explanation of copy on write memory sheds light on why I was experiencing the unsharing of memory.

I do have another related question: are there any methods for sharing a process (or a Perl object) among processes? For example, I want one shared object to update the data structure, to ensure integrity and to write the changes back to the persistent storage. Or is there a better method for handling this than one shared object attempting to service many requests?

  • Comment on Re: Re: Sharing data structures among http processes?

Replies are listed 'Best First'.
Re: Re: Re: Sharing data structures among http processes?
by pope (Friar) on Jun 28, 2001 at 04:13 UTC
    Having trying myself to implement a semaphore-based locking mechanism for IPC SysV shared memory, I'd recommend IPC::ShareLite for general purposes. It comes with a powerful locking mechanism, which is incredibly similar to flock() !
    Apache::SharedMem also depends on this module.
Re (tilly) 3: Sharing data structures among http processes?
by tilly (Archbishop) on Jun 28, 2001 at 03:36 UTC
    There are many ways to share data between processes. You can use a local dbm file. You can use IPC::Shareable. And so on. But all of the efficient ones have the rather significant problem that all of the requests in your series have to come back to the same physical machine. This does not play well with load balancing.

    However one crazy way of doing it is like this. One machine gets the request and forks off a local server. Other CGI requests are passed the necessary information to be able to access this temporary server, which is run in a persistent process, and then when this server decides the time is right, it de-instantiates itself. This would be a lot of work though.

    Personally I would just see if you can keep the temporary state in the database, and just have each individual request deal with the bit of the state that they need to handle. But I cannot, of course, offer any guesses on whether this would work without knowing more details than you have given us.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://92109]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (4)
As of 2021-04-11 06:29 GMT
Find Nodes?
    Voting Booth?

    No recent polls found