[Rpm-maint] Sigpipe handling in build/rpmfc.c

[Panu Matilainen]

On 06/07/2011 10:14 AM, Michael Schroeder wrote:
> On Tue, Jun 07, 2011 at 09:35:38AM +0300, Panu Matilainen wrote:
>>> IMHO aborting the read when a SIGCHLD occurs is wrong, as the
>>> pipe may still contain unread data (and data is only read in
>>> sizeof(buf)-1 chunks). Wouldn't it make more sense to simply
>>> ignore SIGCHLD and read until an EOF is returned, i.e. the
>>> read returns zero bytes?
>>
>> SIGCHLD needs to be caught to avoid hanging in the select if the child
>> exists without flushing its stdin,
>
> Why? You're reading from the child, so you'll get an EOF when
> the child exits, i.e. if there are no processes left that have the
> write side of the pipe open. It can't hang.

It's also writing to the child ... but ... since it's not actually DOING 
anything with signals, if we just leave SIGCHLD and others alone 
select() should indeed be safe as is. Okay, to which address should I 
send your "I found a classic Daily WTF overcomplication" t-shirt? :)

>
>> but you're probably right the reading
>> side could (in some rather rare conditions) miss some final bits from
>> the child output. Hum, I guess SIGCHLD should only abort the loop if
>> there are unwritten bytes left. Need to scratch head + consume coffee
>> some more...
>
> Just read until you get an EOF (which always happens if the child
> exists), and then return an error if writeBytesLeft is not zero.

It can't "just read until EOF" as in the case of external dependency 
generator, writes and reads can be interleaved on large packages, but 
yes aborting when read gets an EOF seems quite obviously the right thing 
to do, and if there's still something to write at that point its an 
error (which the latter part of the code already checks for)

	- Panu -