On Nov 7, 2011, at 9:13 PM, Gerald Combs wrote:
> GLib is quickly moving towards initializing threads automatically at
> program startup. This is already the case for Gtk+ programs with GLib 2.24:
>
> http://developer.gnome.org/glib/2.28/glib-Threads.html
>
> "Please note that since version 2.24 the GObject initialization function
> g_type_init() initializes threads (with a NULL argument), so most
> applications, including those using Gtk+ will run with threads enabled.
> If you want a special thread implementation, make sure you call
> g_thread_init() before g_type_init() is called."
>
>
> ...and it will be the case everywhere with GLib 2.32:
>
> http://git.gnome.org/browse/glib/tree/glib/gthread.c?h=master
>
> * The GLib threading system used to be initialized with g_thread_init().
> * This is no longer necessary. Since version 2.32, the GLib threading
> * system is automatically initialized at the start of your program,
> * and all thread-creation functions and synchronization primitives
> * are available right away.
>
> 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?
I support this. I don't see a reason why not using them and it only
adds additional stuff to test...
Best regards
Michael
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>
