[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [coreutils] [PATCH] sort: fix some --compress reaper bugs

From: Pádraig Brady
Subject: Re: [coreutils] [PATCH] sort: fix some --compress reaper bugs
Date: Wed, 15 Dec 2010 01:12:23 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100227 Thunderbird/3.0.3

On 14/12/10 18:20, Paul Eggert wrote:
> On 14/12/10 09:55, Jim Meyering wrote:
>> It'd be a shame to make everyone sleep even one second for NFS.
> Well, it is marked as an _expensive_ test.  :-)
> On 12/14/10 02:07, Pádraig Brady wrote:
>> If the subprocesses were reparented to the shell,
>> then one could just `wait`.
> I don't know how to do reparenting like that.

Me neither. I don't know why I thought
they might be reparented to the grand parent.

>  But this raises a
> more general issue: is it OK that when 'sort' is interrupted and
> exits, that it does not kill off its children?  That is, it relies on
> compressors nicely exiting (because 'sort' exits and they read EOF),
> and it relies on decompressors nicely exiting (because they write to a
> dangling pipe and get SIGPIPE or a write failure).  If either
> assumption is false, 'sort' will leave behind orphan processes that
> never exit.

To handle this, you'd have to do something like what `timeout` does.
It creates a process group, so that if you kill it,
you kill everything underneath. This could be handy
in test scripts actually to kill everything in a timely
manner, by just killing a timeout process.
Your test script is fine as is though.

> I'm sort of inclined to say that's OK,

Definitely agreed, considering the type of processes invoked.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]