Re: pkg_add vs. ssh

[Marc Espie <espie_(_at_)_nerim_(_dot_)_net>]

On Tue, Mar 07, 2006 at 08:05:08PM +0100, Marc Espie wrote:
> There was still one big problem left, which is that pkg_add doesn't
> directly run the client, but runs a gunzip process which runs the client:
> killing the gunzip doesn't ensure timely demise of the client process,
> and I was left with a frequent deadlock, since the old client tended to
> swallow the ABORTED answer from the server.
> 
> After more head scratching, I ended up using signal USR1 to communicate
> between pkg_add and its client grand-child, to make sure this one was
> done reading from the ssh connection before I did the ABORT and fired
> the new connection.
> 
> The new code seems to work just fine so fine just far. 

As I suspected, this part was too complicated, and susceptible to some
nasty sigpipe race condition. I ended up switching programming models,
and instead of having a classical 'shell pipe' with a child and grand-child,
having two children, doing the pipe connection manually, and micro-managing
the second child. The nice end result is that I can close($fh) on the gzip
handle and waitpid($object->{pid2}, 0) on the connection process, so that
I can be sure it died before I send the ABORT message. The only not nice
result is that I have to micro-manage those processes, e.g., make sure I
do both the close and waitpid each time (not too bad), and not forget
to close everything as expected...

There's one local area where the code is more complicated, but in general,
the processes interactions are greatly simplified, and stuff now happens
in a deterministic way...