[Guy Harris <gharris@xxxxxxxxx>]

Ulf Lamping wrote:
> Guy Harris wrote:
> > Also, the third of them is a bit odd to implement - would it just 
> > freeze the packet list display, but add packets to it, and then thaw 
> > the packet list display when you stop the capture?
>
> I don't tend to fill the packet list already at that stage (because of 
> the machine load to do that). It should work just as today, loading the 
> packet list when the capture is stopped. That needs some redesign of the 
> capturing engine in the main code, yes.

...and it'll have to do more work if the child doesn't look at the 
packets it captured to count packet types, but leaves that up to the 
main process, as the main process will have to read the capture file to 
do that.  (I.e., if the main process generates the packet counts window, 
that'd probably *increase* the chances of packet drops, unless the only 
count it displays is the total packet count, as it can get that from the 
child without reading the capture file.)

> Summary: The capture process won't show *anything* by itself.

That's as it should be.  That means that the capture program will be 
smaller and simpler, *and* that it can, on UN*Xes where you need root 
privileges to capture, set-UID to root (GTK+ programs can't be set-UID 
root - GTK+ refuses to run in a set-UID program, because they have 
inherent unfixable security holes due to theme code they load at run time).