Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

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

by Eyck (Priest)
on Sep 21, 2005 at 10:17 UTC ( [id://493714]=note: print w/replies, xml ) Need Help??


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

I'm sorry, but it seems like you're playing with databases and everything looks like a nail.

Proposing additional and significant external dependencies for a nice self-contained program is not very smart.

Replies are listed 'Best First'.
Re^3: How to tell a child what to do?
by Corion (Patriarch) on Sep 21, 2005 at 10:32 UTC

    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.

      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.
Re^3: How to tell a child what to do?
by eric256 (Parson) on Sep 21, 2005 at 20:29 UTC

    You know it might actauly be a nail in some cases. It is odd that you ask a question and then are soo rude when you get an answer. Databases can be the right tool and they might not be. That depends entirely on your situation. If you wanted to have 100 children spread over 100 computers then a database would be a perfect solution. You said you wanted "possibly non-blocking and reliable way". Database is *one* of the answers that fits the question. For instances I work on windows and linux boxes and never feel comforatble with forking or "traditional" IPC. However I am always working with databases and most scripts I write use databases for something (not out of habit, i work with large sets of scheduling and accounting data in a database). In my case lots of times a DB is the easiest, fastest and most comfortable route for my problems. As far as we knew you where already connected to a DB and this would be a good solution.

    "Proposing additional and significant external dependencies for a nice self-contained program is not very smart." -- Considering we don't know the current dependencies of your program, we could hardly deduce that a database wouldn't fit your needs.

    Ask a question, get lots of answers, don't critise an answer or mock the person giving it just because it doesn't fit your need. We can't read your mind or know your particular needs or desires unless you tell us first. Sorry for the rant but its realy hurts to see someone try to help and provide a fair answer and be treated the way you tried corion.


    ___________
    Eric Hodges

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others lurking in the Monastery: (5)
As of 2024-03-29 12:36 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found