Ethereal-dev: Re: [Ethereal-dev] Capturing engine: Stop the capture child gracefully on Win32
Ulf Lamping wrote:
So I started investigating what can be done against this. After doing
some in depth Google and MSDN search and a lot of try and error, I ended
up in implementing a second pipe from the parent to the child to send a
quit message to the child. This is Win32 only, so the unix version
shouldn't be affected at all.
The pipe probably won't be checked if the child is blocked waiting for a
packet to arrive on a pcap_t; fortunately, the WinPcap driver provides
an underlying packet capture mechanism that has a timeout and where the
timeout starts running when the application starts waiting for a packet
(rather than starting when the first packet arrives, as is the case with
SunOS 5.x's bufmod and, I think, in 3.x's and 4.x's NIT mechanisms).
As such, although the child won't necessarily stop *immediately*, it
should stop after the timeout expires, which is 1/4 second, so that's
probably good enough.
In theory, the child process could, on Windows, do a
WaitForMultipleEvents() (or a MsgWaitForMultipleEvents() - as I
remember, the GLib main loop does one or the other of those, depending
on whether it's waiting for a GUI input event on behalf of GTK+ or not),
and perhaps wait for input from the pipe or for packets to arrive, but,
in older versions of WinPcap, the pcap_getevent() implementation was
buggy on Windows NT (as I remember, the problem was that some code was
compiled with the "Unicode" flag on and other code was compiled with the
flag off, so they didn't have the same idea of how the pcap_t structure
was laid out, and pcap_getevent() returned a value from some random
chunk of memory), so that couldn't be guaranteed to work.
