http://www.perlmonks.org?node_id=493717


in reply to Re^2: How to tell a child what to do?
in thread How to tell a child what to do?

I'm sorry that I misunderstood your problem. I thought that your statement:

The hard part seems to be communicating with children, with one child, I would probably use STDIN/STDOUT, servers like apache have symmetrical children, so I'm kind of lost as to what is the best way to do something like that.

implied that your children are not symmetrical and maybe even distributed across machines, and that children die-ing from unknown reasons might be common.

Maybe you should discuss the scope of your program in the original post to some larger extent - I found DBD::SQLite a very convenient, lightweight and self-contained database, for example.

Replies are listed 'Best First'.
Re^4: How to tell a child what to do?
by Eyck (Priest) on Sep 21, 2005 at 10:50 UTC

    While I used DBD::SQLite in few projects and also found it to be convenient, lightweight, and relatively self-contained when it comes to databases, database is not a solution for communication problem. unless it is, but I just fail to see the reason to go through all the hassle of seting up a database

    Since all the communication is with my own children, setting up an external file ( be it SQLite, which I fail to see how would it be relevant, something lighter like DB_File, or even single file with locking, or even socket with external daemon ), seems a tiny little bit overblown, don't you think?

      No - to me, that does not sound overkill. But that is because I try to avoid IPC in Perl and want to be able to easily audit what the children are doing, and what jobs came when. Also, I like the scalability that a database-based IPC mechanism provides - you can quickly add new machines to the setup which take their jobs from the database.

      You said The hard part seems to be communicating with children, and I tell you a way that makes it trivially easy to communicate with the children, without any ugly interlocking problems and race conditions because of how (SQL) databases work. If you don't want to use what I propose feel free to do so, but don't dismiss it as unusable, as it is easy to implement.

      A reply falls below the community's threshold of quality. You may see it by logging in.