On Wed, 16 Mar 2005 09:14:38 +0000, Athanasios Anastasiou <[EMAIL PROTECTED]> wrote: > After some directions from Liam (see yesterdays mailing archive) i > passed my app through valgrind and found out that there are too many > errors happening in the GTK / X level. I suppose that it has something > to do with the way i am using the thread library in combination with GTK.
There are two ways to do threads in GTK: 1) do threads_init, then put threads_enter/threads_leave around *every* gtk/gdk call which could be called from more than one thread. There's a FAQ about this approach: http://gtk.org/faq/#AEN482 2) have a single GUI thread (ie. all gtk/gdk calls are from one thread), then background worker threads can trigger callbacks in the main thread to ask it to do work on their behalf via g_source_*() On pros and cons, (1) is painful and error prone, IMO, and very hard to use for large apps. Whereas (2) keeps threads separate with well defined synchronisation points. As I said, (2) works for me on a large (>100,000 lines of C) GTK program. > I refrained from using the callback mechanism ( as you suggest) because > whatever code is executed within there should execute in a time shorter > than the "packet length". Hmm, I guess it depends how much work the consumer needs to do. If it's several ms of CPU per packet, I guess you will need a separate thread for this. I'd still recommend keeping the GUI single-threaded and having workers wake it with GAsyncQueue. You could have your producer/consumer threads communicating with your list, then the consumer sending "please queue a redraw" messages to the GUI down the GAsyncQueue. > You are talking about a GAsyncQueue, now thats something i havent looked > at. Another thing i havent looked at is threads in glib....I suspect > that a lot of bad things occur when my "processing" thread tries to draw > the signal on the widget because at some point i discovered that the > thread lags and blocks (mind you there is nothing else in the processing > thread except the plot code) That sounds bad. You must only plot in the "expose" handler, things will break otherwise (maybe I misunderstand). glib threads are a very simple portability wrapper over the win32 and posix thread libraries, there's no magic there. > event handler handles the rest...... (And the question now arrises, what > happens if an expose event from the app collides with an expose event > that had to be sent because the user minimized and maximized the > application???) GTK has a complicated thing that handles this for you. All exposes, whatever their cause, go through the single "expose" handler in a sensible way. J _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
