AnyEvent::Fork clarification

[Vikas N Kumar]

On 01/07/2014 10:07 AM, Marc Lehmann wrote:
> 1 when you want your code to be portable and it uses pthreads (for example,
>   if IO::AIO is installed then AnyEvent might load it in the background,
>   creating some threads as side effect).
> 3 when you want to do actual work in the forked process without having to
>   think about destructors, shared resources such as handles and so on.
>
> I would say 3 doesn't apply to you, and 2 probably neither (but faster is
> never wrong), and I don't know at all if 1 applies to you.

Well my scenarios is that I have a Perl GUI built using Prima, and after
some user manipulation of data it needs to run a bunch of C++ processes
(which will use threads) with that data in parallel over a cluster of
computers (which could be local or remote via ssh).

I have tried AnyEvent::Fork and AnyEvent::Fork::Remote and I prefer
AnyEvent::Fork and using Net::SSH::Perl + AnyEvent::Fork over
AnyEvent::Fork::Remote since the latter needs me to fork an ssh command
line process as well. Net::SSH::Perl allows for the process to fork
locally but perform the ssh and then execute the task remotely and all I
need to do is track the local process.  This allows for filehandle
send_fh() call to work which is needed to track if the child completed.
Net::SSH::Perl automatically handles the STDOUT/STDERR file handles and
that is useful to have in my scenario.

So once the C++ processes are complete the results need to be parsed
back and displayed in the GUI.

This is why I am trying to track each child that completes in order as
opposed to just waiting for the last child. I am trying to avoid using
tricks such as having log files for each child to track their exit.

Thanks.
Vikas.