Re: g_thread_init, gdk_threads_init, gdk_threads_enter and Gtkmm



Evgeny Repekto wrote:
Some days ago I asked about Xlib async error. It seems I solve the
problem but in one point I'm still getting dead lock. Is it critical
to put
	g_thread_init(NULL);
	gdk_threads_init();
before
        Gtk::Main Kit(argc, argv); ?

What I have now is:
        Gtk::Main mKit(argc, argv); //<--- this is first
	g_thread_init(NULL);
	gdk_threads_init();
	gdk_threads_enter();
	Gtk::Main::run(mMainWindow);
	gdk_threads_leave();

The gtkmm documentation says to do the following before using any thread-related facilities:

	if(!Glib::thread_supported())
		Glib::thread_init();

This has worked fine for me. It happens to be in my main window's constructor in my current project, but it's probably not a bad idea to put it at the start of main() if your application is always going to make use of threads.

Make sure you use the Glib::Mutex/Glib::RecMutex and their nested Lock classes to best avoid problems such as dead-lock. Using scope/RAII to control locking is much safer than using general lock/unlock functions from any threads framework.

Edd



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]