[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:1.9.1.8) 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.
cheers,
Pádraig.