Re^2: fixed set of forked processes

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

Comment on Re^2: fixed set of forked processes

Replies are listed 'Best First'.
Re^3: fixed set of forked processes by Illuminatus (Curate) on Dec 02, 2010 at 18:14 UTC
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]
Re^4: fixed set of forked processes by anonymized user 468275 (Curate) on Dec 02, 2010 at 18:25 UTC
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]