On 07/20/2010 03:17 PM, Paul Eggert wrote: > On 07/20/10 14:11, Eric Blake wrote: > >> Hmm, maybe we should do more validation in the parent - not just read >> from the fifo, but validate that we actually read a token. That way, we >> can ignore EOF (on the grounds that it may be a temporary condition, and >> that more children remain to be run) and only advance when the token we >> read back is non-empty. > > That would be better than now, but taking a step back, why are we using > a named fifo at all? Why not simply use a pipe? Then we wouldn't have > to worry about all this after-you-Alphonse business. Children could > write to the pipe when they're done. The parent could read from the pipe > to find out when a child died.
How do you propose to set up the pipe in the parent in a way that you
can control which fd it is tied to in the child? The only way I know to
do that is via a named pipe (aka fifo).
Unless maybe something like this would do (untested)...
exec 7>&1 # save orig stdout
{ exec 6>&1 1>&7 # save pipe's stdout, restore stdout
for each child do
wait for permission from parent to start test
(
test
echo >&6
)&
done
} | {
wake up n children
for loop that reads stdin, and wakes up children as data comes in
done
prune remaining n reads off stdin
}
exec >&7 7>&-
But how does a child block until the parent is ready for the next
parallel group, and how does the parent signal that a child can run?
Here, maybe one named fifo per child will work, where the child blocks
by doing:
exec 8>test-specific-fifo
the parent wakes it by doing:
exec 8<test-specific-fifo
then both processes can close the fifo, without doing any I/O over the fifo.
And how does signal handling fit in with interrupting a child test?
--
Eric Blake ebl...@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
