On Nov 7, 2011, at 12:13 PM, Gerald Combs wrote:
> Is there any reason we shouldn't remove the thread options from
> configure.in and CMakeOptions.txt along with USE_THREADS and hard-code
> thread support?
When I got started with Wireshark development (back when it was still called Ethereal), I think some of the platforms on which it ran didn't have threading support, and others had somewhat limited user-mode threading support, with wrappers around some system calls and its own internal select()-based event loop, that worked except when it didn't, and "where it didn't" may have included applications that had their own event loops (I don't remember) *and* applications using BPF.
1998 called, it wants its threading model back. :-)
I think the pthreads in all the UN*X platforms we currently support should work well enough for our purposes, and GLib also handles Windows threads, as far as I know. (In fact, if the threading on a platform doesn't work well enough, GLib probably won't support that platform in the future; there was a time when we didn't require support for 64-bit integral data types in the C implementation, but GLib now requires it, as do we, and this looks as if it's a similar case.)
