- Make a background thread to do the sniffing with g_thread_create(). Make
a pipe, and have the background thread write its results to the pipe.
Do gtk_input_add_full() to make your foreground thread wake up when things
are written to the pipe. When stuff arrives, update the screen.
Why have a pipe. Why not have an area of memory where the data is stored. A semaphore to avoid the two threads accessing at the same time and a dirty flag.
The sniffer thread updates this area every time a new packet comes in and sets the dirty flag.
The gui thread has a timer with a callback which reads this area and updates the display and resets the dirty flag.
It may be that several packets come up before the display updates and it might be that none come in. Obviously the display only needs to update if the dirty flag is set.
Yes, also a good solution. I usually use a pipe because you don't need a mutex, you don't need the polling in the GUI thread, and you won't miss updates if you're too slow.
You're also right that for a (potentially) high-volume thing like a packet sniffer there will have to be some mechanism for throwing away data when it's coming in faster than the GUI can repaint. For the pipe implementation, I guess the GUI would have to read-until-empty on the pipe when it woke up, then just use the last packet to update the screen.
John _______________________________________________
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
