Re: [gtk-list] Re: CList updates
- From: Owen Taylor <otaylor redhat com>
- To: gtk-list redhat com
- Cc: trog gtk org
- Subject: Re: [gtk-list] Re: CList updates
- Date: 18 Jan 2000 07:53:23 -0500
Matt Goodall <mgg@isotek.co.uk> writes:
> Owen Taylor wrote:
> >
> > Matt Goodall <mgg@isotek.co.uk> writes:
> >
> > > Owen Taylor wrote:
> > >
> > > <snip>
> > >
> > > > Thread support in GTK+ definitely works if you know a few
> > > > simple rules. There are some fairly significant apps using
> > > > it - gFTP and the Red Hat installer, to list a couple.
> > > >
> > > > The necessary rules should be covered in the section on
> > > > threading in the GTK+ FAQ.
> > >
> > > Thanks Owen,
> > >
> > > I went back to my test code after you said it definitely does work and
> > > started playing with it again. I've got this widget structure:
> > >
> > > GtkWindow
> > > GtkScrolledWindow
> > > GtkCList
> > >
> > > The problem appears to be that I was adding the clist to the scrolled
> > > window using gtk_container_add(). Once I changed this to use
> > > gtk_scrolled_window_add_with_viewport() it started working perfectly.
> >
> > Well, not to make things difficult :-), but you _do_ need to use
> > gtk_container_add(). If you use gtk_scrolled_window_add_with_viewport(),
> > then you'll have the the following problems:
> >
> > - The column titles will scroll with the clist
> > - Your CList will be limited to 32,768 pixels in height
> >
> > I can't really see how this has any relation to threading, but
> > maybe there is some really funky interaction going on.
>
> Finally got some time to go back this...
>
> I've put it back to gtk_container_add() as you (and others) recommended
> and it definitely doesn't work quite right. Basically the thread is
> doing this:
>
> while(...)
> {
> gtk_threads_enter();
> gtk_clist_append(...);
> gtk_threads_leave();
> }
>
> Anyway, this doesn't update the clist correctly but adding a gdk_flush()
> before the gdk_threads_leave() seems to solve this and everything is ok
> (again).
>
> I don't remember reading anything about gdk_flush() related to threads
> so is there a problem somewhere or was I supposed to do that all along?
It's basically something that you need to do manually in a few
spots when using threads.
The problem is that normally the X queue gets flushed when the event
loop goes idle, but only the main thread ever goes idle, so if you are
doing things from an auxilliary thread, then you need an explicit
calls to XFlush() when you are done making GDK/GTK+ calls and you
want the results to show up on the screen.
We could automatically do an XFlush() at each gdk_threads_leave, but
this could conceivably be a fairly big loss of performance for an
application that took up and released the lock in a fine grained
manner, so I'm reluctant to make the change.
Regards,
Owen
P.S. -
Incidentally, there is a problem now that gdk_flush() actually
calls XSync() and not XFlush(), and the latter is all we need.
If performance is a big issue (it shouldn't generally matter),
you might want to write your own flush_requests() that
was
#include <gdk/gdkx.h>
void flush_requests()
{
XFlush (GDK_DISPLAY());
}
P.P.S -
Tony,
If you could add this to the FAQ, I think it would help people
trying to do threading a lot. Thanks.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]