in reply to fixed set of forked processes

I think a few more details are in order
  1. How will the jobs actually be run? You mention fork, but not exec or system
  2. If you want to communicate between parent and child, you probably don't want file-based IO. You would probably want IO::Socket instead. Use socketpair to create 2-way communication
  3. If you aren't going to exec the child into the jil job, you are probably better off using threads. Then you can simply use shared data to communicate and manage the children

fnord

Replies are listed 'Best First'.
Re^2: fixed set of forked processes
by anonymized user 468275 (Curate) on Dec 02, 2010 at 18:06 UTC
    It would be IPC:: open3 or run3 the child will then handle the results of it's own spawning. The parent only needs to know whether the child is still alive. So the communication is a bit fake -- Parent only wants to know if closing the IPC filehandle to the child fails, signifying that the child has exited -- all this assuming there isn't another way to know if the child lives.

    update: or rather closing the filehandle is what perlipc suggests but what if I need to poll repeatedly for exited?

    update: socketpair is just a wrapper to what I already discussed. It complicates the question of how to create the multiple filehandles and still leaves the question of how to destroy them.

    One world, one people

[reply]
      have you looked at threads? You can create the threads, then use is_running to check if they are alive. If you need to pass actual data, you can use the aforementioned shared data.

      fnord

[reply]
        That will be okay for now, although the day will come when the client wants to upgrade to perl 5.10.whatever+ which no longer supports threads. So I will resort to that only if necessary. I already looked at the fork-based drop-in replacement of threads and all my issues here remain unresolved for that.

        One world, one people

[reply]

In Section Seekers of Perl Wisdom