RE: GTK and threads
- From: "Vlietstra, Joe (NSSD)" <Joe Vlietstra ngc com>
- To: <gtk-list gnome org>
- Cc: "Yan, Gordon \(NSSD\)" <Gordon Yan ngc com>, "Ippolito, Gregory F. \(NSSD\)" <Gregory Ippolito ngc com>
- Subject: RE: GTK and threads
- Date: Mon, 28 Feb 2005 08:53:35 -0800
Sven Neumann <sven gimp org> writes:
> "Vlietstra, Joe (NSSD)" <Joe Vlietstra ngc com> writes:
> > Our group has previously written several multithreaded GTK
> > applications. We had a problem with a new application,
> > investigated, read the API docs, and now we are completely
> > confused about GTK threads.
> >
> > The example applications in the API documentation contain
> > the following code snippet:
> > gdk_threads_enter();
> > gtk_main();
> > gdk_threads_leave();
> > gdk_threads_enter() is simply a wrapper function that locks the
> > gdk_threads_mutex. Similarly, gdk_threads_leave() is a wrapper that
> > unlocks the mutex. This means GTK main loop has a lock on the mutex
> > and apparently holds this lock until the main loop exits. If GTK
> > main is always holding the mutex, how can other threads acquire the
> > lock?
>
> Have a look at gtkmain.c. The lock is (of course) released while the
> main loop is being run.
Thanks.
A quick review of gtkmain.c solved the gdk_threads_mutex mystery.
Our thread collision problem disappeared when we installed GTK 2.6.2 on
our target machine. Couldn't find the bugzilla entry that corresponds
to our original problem (threads, Win32) but I'm closing the issue with
"upgrade to GTK 2.6.2".
Thanks again,
Joe Vlietstra
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]