On 06/06/2011 02:40 PM, Michael Schroeder wrote:
Hi guys,
what's the reason for the complex pipe handling with sigpipe_handler(),
sigpipe_init() and sigpipe_finish()?
The point was to make it more robust:
a) use blocking io instead of spinning on a timeout that will inevitably
be wrong for some case somewhere
b) be tolerant against errors, such as missing script interpreters and
bad arguments which cause the generator helpers to exit before reading
their stdin at all
Both being more important than before now that we're encouraging
packagers to add dependency generators on their own instead of piling
everything into rpm itself.
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, 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...
Mind you, I do agree the thing is more complex and error prone than I
care for. On more than one occasion I've considered replacing it with a
dirt-simple setup using temporary files and letting the shell deal with
the pesky little details.
- Panu -
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
