Re: [gtk-list] Re: XInitThreads causing problems to GTK windows.
- From: Sebastian Wilhelmi <wilhelmi ira uka de>
- To: gtk-list redhat com, Olaf Klischat <olaf klischat tu-clausthal de>
- Subject: Re: [gtk-list] Re: XInitThreads causing problems to GTK windows.
- Date: Thu, 15 Jul 1999 16:02:42 +0200
Hi, Olaf
> > Just don't use XInitThreads(), as it will slow down things additionally
> > and gtk already takes care of that. But you have to call g_thread_init()
> > before the call to gtk_init(). And then you have to call gdk_thread_enter()
> > before any call to gtk/gdk-function and gdk_thread_leave() afterwards; not
> > within
>
> Is that necessary even if I don't call gtk functions from anywhere
> _except_ the main thread?
No, than it isn't necessary. You have to call g_thread_init() however to make
GLib thread-safe. You can than also use the portable GLIb thread system for
things like mutexes.
> Is it possible to establish a communication link between the main thread
> and some separate 'worker thread' based on (X- ?) Events?
Yes, but that is in general much more work than just calling
gdk_threads_enter() before the command itself and gdk_threads_leave()
afterwards.
> So, every time
> the worker thread wants to GUI to be updated somehow, it might post a
> message into the main thread's message queue (does each thread have a
> separate message queue, like in Win32? I don't think so..).
There aren't message queue, unless you program them. They would have to be
prepared to take all actions, that a worker thread might issue. If those
actions are only a few (update a progress bar and such) it is quite easy, but
if the worker thread wants yo use much of the gtk-API it is easier the other
way.
> At some later time, the main thread reads that message and performs the
> required GUI work.
> How could this be done?
Define a struct, that can hold all the actions you would want to do and make a
GQueue hold them. Add from one thread, read from the other. As noted above. In
general don't do that.
> > signals, as they already hold the lock but also before gtk_main() and
> friends.
>
> A silly question: What do you mean by 'signals'? GTK signal handlers? Or
> something that has to do with Unix process signals? I'm not yet very
> familiar with unix programming, so excuse my lack of knowledge...
I of course mean GTK+signals here.
Tschüß
Sebastian
--
Sebastian Wilhelmi | här ovanför alla molnen
mailto:wilhelmi@ira.uka.de | är himmlen så förunerligt blå
http://goethe.ira.uka.de/~wilhelmi |
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]