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 -
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Reply via email to