AnyEvent::Fork clarification

[Marc Lehmann]

On Tue, Jan 07, 2014 at 10:23:46AM -0500, Vikas N Kumar <vikas at vikaskumar.org> 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.
> >
> 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).

As long as you can keep threads out of your prima program and just call exec
anyway in the child, fork or anything using fork will be ok.

> I have tried AnyEvent::Fork and AnyEvent::Fork::Remote and I prefer
> AnyEvent::Fork and using Net::SSH::Perl + AnyEvent::Fork over

The point of AnyEvent::Fork::Remote is that it creates a perl process
remotely - you don't have to use ssh for that. Conversely, Net::SSH::Perl
creates a (very slow) ssh connection, it doesn't bootstrap a perl process
on the other hand.

If all you need is to run some command via ssh, then
AnyEvent::Fork::Remote would probably just be in your way.

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

If the results are simple, you could just write them to the fh you get
from e.g AnyEvent::Fork.

> 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.

I also prefer to keep things off-disk unless really necessary. Temporary
files are just so ugly.

On Tue, Jan 07, 2014 at 11:02:07AM -0500, Vikas N Kumar <vikas at vikaskumar.org> wrote:
> On 01/07/2014 10:07 AM, Marc Lehmann wrote:
> > This will have the effect of any process you exec (and any process that
> > process execs) to inherit the fd, which will therefore stay open as long
> > as at leats one of the processes started is still running, which might be
> > better (or worse) then waiting for the exec'ed child.
> Yes this was it. This is absolutely needed to track if the child has
> exited. When the inherited fd is closed by the child on its exit the
> parent gets notified every time which is what I wanted !

Well, to be overcorrect: it will only notify (by EOF) the parent when the
child and all its forked (but not exec'ed) children have exited.

Which, I *guess*, is exactly the same as what you said in your setup.

And if that is ever a problem, you could always use a more complicated
protocol, such as the child writing "i am about to exit" to the socketpair
:)

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\