How did you get an attachment to work with the list? I have never known that to work and often wished it would.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Torrie Sent: Monday, February 06, 2006 1:22 PM To: kornelix Cc: gtk app dev mail list Subject: Re: GTK and threads kornelix wrote: > Thanks. I eagerly anticipate your example. I have attached a sample file that uses threads in the way you described in your last post. The gui consists of a single text display and a button. When you click the button, a new thread is started that periodically (every second) sends a message to the text window. When you close the window, the program will send a signal to each thread to terminal (well not a real signal, just sets a flag). Once all the threads have terminated, the program ends. I have not implemented a proper signalling system to send signals to the threads nor have I used the pthread_join to properly rejoin threads that have quit. Mainly because pthread_join blocks and that causes problems. You'll notice the on_destroy callback has a loop that iterates the gtk event loop while we're waiting for the threads to stop. This is because we're in a callback, already holding the gdk_thread_lock, so any waiting in here will prevent threads from aquiring their lock and thus finishing their loops. So we iterate it. The callbacks (including the pthread_create calls) already occur in the context of the main gdk lock, so no explicit locking is needed there. See what you think. > > I made a small code example like the one you described. It hung up. Then > I figured out why: I am calling a function that has the > gdk_threads_enter() and _leave() wrappers from main() as well as from a > created thread. In the case of main(), the call to gdk_threads_enter() > was a second call for that thread, and this is apparently fatal. I have > to figure out how to detect and avoid this, or make multiple versions of > the functions with and without the wrappers. If I call the function from > the thread only, it works. > I really am not following what you are describing (please provide code) but it feels like you're definitely doing something wrong. It needn't be this complicated from my experience. > One way of looking at the issue is that the FAQ example includes all > main() code within the thread wrapper functions, meaning that any called > functions better not have the wrappers. Would it be legitimate to treat > main() like any other thread, and put the wrappers only around gtk/gdk > calls? If I could do this, then functions would be usable from both > main() and created threads. Hmm. Sounds complicated. My gut feeling is that most of your difficulties are in not knowing when you are in the gdk lock already and when you need to initiate a lock. Please tell me if my example code addresses any of the problems you have been having. (and for the real GTK experts out there, feel free to point out where I'm doing everything wrong.) Michael > > It will not take long, so I will just try this. > > regards > > > _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list