Re: Making threads mandatory

[Guy Harris <guy () alum mit edu>]

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.)

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe