This is more of a long-term thing, but what do people think about
having support for using threads in Ethereal?
Due to the lack of portability in threading implementations, I
wouldn't even suggest removing the fork-and-tail method currently in
place; rather, I suggest this as an alternative.
We're currently using Gtk and Glib. Glib has support for
[somewhat] cross-platform threads. So /in principle/ it is possible to
implement threads and have them work on most of the platforms on which
Ethereal runs. On the others, they just wouldn't --enable-threads in
configure.
The reason I suggest this is because ethereal basically uses two
active loops during a capture: a gtk_main loop, and a wiretap capture
loop. And in the end, they manipulate the same data. It is an ideal
candidate for threading.
Since gtk is now thread-safe, we can have gtk functions called
from any thread. This would be a nice way have the "Stop" button on the
packets-captured window actually stop, /without/ waiting for another
packet to come through. (it isn't so bad at work since there's always
traffic, but it's annoying at home when I'm testing code... not a
necessity, but a nicety.)
Even assuming a non-threadsafe gui toolkit, if we keep the
cross-drawing to a minimum, we can easily implement locking at the
end-program level.
As I said, just an idea at this point. I have neither inclination
nor time to do anything more than ponder it for a good long while yet.
Questions / comments / constructive-criticism?
- Bibek
