Hi, -- 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 ...
Thanks && Ciao Alvar -- ** Alvar C.H. Freude, http://alvar.a-blast.org/ ** http://www.assoziations-blaster.de/ ** http://www.wen-waehlen.de/ ** http://odem.org/
pgpfjmNE43fe5.pgp
Description: PGP signature
