Re: forks: shared variables between different applications or hosts

At 11:57 AM +0200 7/3/07, Alvar Freude wrote:
>-- Elizabeth Mattijsen <[email protected]> wrote:
>>I'm afraid I have been responsible for that notion.  But since I'm not
>>the maintainer of forks anymore, you will need to take it up with the
>>current maintainer.  And patches are always welcome, of course.
>Have you any hints where too look in the source? ;-)
>
>>The main problem I see is in developing a protocol linking "shared"
>>variables: standard ithreads implementations don't need this as only
>>variables can be shared that already exist before a thread starts (aka
>>a fork() is done).
>
>hmmmm.
>
>yes; the only
>
>>
>>
>>>I'm in the planing state of an (forking) application, which gets
>>>some commands from another application and it might be very easy to
>>>use such a feature instead of manually freeze/thaw the data and send
>>>it via manually opened sockets.
>>
>>Well, if you would start the "other" application as a thread using
>>forks.pm, you should be able to share variables that way.
>
>one application will be made with mod_perl.
>
>My Problem is, that I need about 100 MB data persistant in RAM for 
>fast hash access. At the moment I do this by building the hash at 
>Apache startup, and all is shared between the childs. But sometimes 
>there are changes ... and then Copy-on-Write un-shares the data and 
>the Apache eats more and more memory ;-)
>
>My idea is to write a daemon (using forks.pm) which can be connected 
>by the mod_perl part; on updates, I shut down all children of the 
>daemon and restart them (as needed).
>
>So the next idea is, that the  mod_perl app can talk directly to the 
>worker childs. But as more as I think about this, this seems to be 
>nod good idea and more complicated then sending some freezed 
>commands over a socket ...

Yes, I think you're making things overly complicated.

Would a regular graceful restart not fix your problem as well?


Liz