> One possibly-nice side-effect is that we might then be able to avoid one
> copy when doing an "Update list of packets in real time" capture
...and one not-very-nice-at-all side-effect is that, given that there's
only one Ethereal process, if, during such a capture, Ethereal blocks
doing a DNS lookup from a balky server, the *capture* blocks, and
packets may be dropped.
So much for that idea.
Perhaps, instead, we should have all captures run with two processes,
with the capture dialog box with the packet counts and "Stop" button
managed by the *main* process, and with the child just sending over the
sync pipe updates to all the packet counts; when the "Stop" button is
pressed, the parent could send a signal to the child, causing it to
close down the capture stream, flush out the last data in the file, and
exit. The parent process would then not have to read from the capture
stream, and thus wouldn't need to have timeouts work; the child process
would not have to handle any user input, and thus wouldn't have to
periodically break out of the read on the capture stream, and thus
wouldn't have to have timeouts work, either.