> We're currently using Gtk and Glib. Glib has support for
> [somewhat] cross-platform threads.
"Cross-platform" in what sense?
The main threading APIs that exist in UNIX-flavored systems these days
are
1) "UI [UNIX International] threads", a/k/a "Solaris threads",
that being the "thr_XXX()" calls that are available on
Solaris and, I think, on at least some other SVR4-flavored
systems;
2) POSIX threads, a/k/a "pthreads", either in the form specified
by the second edition of POSIX 1003.1 or by various POSIX
drafts.
The page at
http://www.gtk.org/rdp/glib/glib-threads.html
says
Currently there is only as much thread support included in GLib
as is necessary to make GLib itself multithread safe. Future
versions of GLib might contain functions to actually create
threads and the like. For now the most portable way to create
threads is to require the macro G_THREADS_IMPL_POSIX to be
defined and use POSIX threads then. This will work on almost
all platforms (except most notably Solaris).
I.e., GLib doesn't itself contain a cross-platform thread package;
threaded applications have to use an OS-native thread API.
I'm not sure why they assert that POSIX threads won't work on Solaris;
perhaps they're thinking of the older Solarises that had only "UI
threads", not POSIX threads. Solaris as of 2.5 or so has had POSIX
threads as well as UI threads.
> 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.
Yes, but that's just because "libpcap" isn't polite enough to provide a
call to get, from a "pcap_t *" created with "pcap_open_live()", a UNIX
file descriptor for the BPF/DLPI/SOCK_PACKET/whatever object from which
the raw packets are being read. If it did (and if that object supports
"select()"), and if it supplied a "read packets from a 'pcap_t' routine"
rather than just "pcap_loop()", you could probably just add that
descriptor as one on which the GTK+ main loop should select, set it to
be non-blocking, and have the callback for that descriptor read packets
until it gets a "sorry, no more packets yet" return value.
That's one of a number of things I'd like to fix in Wiretap eventually;
probably the hardest thing that needs to be done to be able to
completely replace "libpcap" is a BPF code generator - the rest looks
straightforward, although perhaps time-consuming.
