Re: gtk & threads

[bob cs csoft net]

On Thu, 2 Sep 1999, Tom Gilbert wrote:

> * bob@cs.csoft.net (bob@cs.csoft.net) wrote:
> > 
> > On Wed, 1 Sep 1999, Tom Gilbert wrote:
> > 
> > > * bob@cs.csoft.net (bob@cs.csoft.net) wrote:
> > > > Is gtk thread safe?
> > > 
> > > The answer is a cross between kind-of, and yes.
> > > 
> > > Basically though, yes. Although not technically thread-safe, it is
> > > close to being so.
> > > 
> > > The thread-safety rules basically go as follows:
> > > o call g_thread_init() before gtk_main() or any other gtk/gdk/glib calls.
> > > o When using gtk/gdk calls, always surround them with gdk_threads_enter()
> > >   and gdk_threads_leave().
> > > 
> > > While this is technically not thread-safe behavior (since thread-safety
> > > means that the gtk/gdk calls do this themselves), it is close enough in 
> > > practice for most people. (Extra typing not withstanding ;)
> > 
> > I see. Question. How difficult would it be to modify all the gtk/gdk
> > functions to do it themselves, and have the callbacks spawn off the
> > function they call in a new thread? If it is not too dificult, just time
> > consuming, I would be willing to give it a stab.
> 
> Ouch. This would be a big job. I also think you will meet much
> resistance from people who don't use threads, who would then inherit
> their overhead (however large or small) from the gtk functions.
> 
> It really isn't that hard to do though, you could check out the code
> of gftp, which contains several good examples (IMO) of the use of threads.
> 

Hmm, How about this. Make all the functions thread safe. then duplicate
the signal connect function to a second threaded one.
so if they call gtk_signal_connect() it calls the connected function.
If they use gtk_thread_signal_connect() it spawns the function off in its
own thread.

that way, you can create more complex programs that dont use threads, or
you can simplify (and in some ways complicate) the program using the
second function.

It would be similar to gnome vfs. you can code without worying (much)
about the threading.

> > The result would be that you no longer have to wory about coding strange
> > to get around the refresh problem and a user can press 2 buttons 1 after
> > another with the first function running at the same time as the second.
> > The programmer would not know that, internally, gtk was using threads. I
> > think it would simplify coding alot. To do a simple percentage bar that
> > goes from 1 to 100% would only take a simple for loop.
> 
> I don't think threads are the only answer here. There are many ways to
> make your program responsive without the introduction of threads. This
> basically boils down to programmer preference, but I personally
> wouldn't do it that way out of choice. Threaded apps can be an
> absolute _nightmare_ to debug, and the programming overhead in terms
> of proper locking etc can be very time consuming.
> 
> However, in _some_ situations, threads are very useful. It depends
> very much on the application, and I don't know what it is you're
> trying to do...
> 
> Your call.
> 
> Tom.
> -- 
>             .-------------------------------------------------------.
>     .^.     | Tom Gilbert, England | tom@tomgilbert.freeserve.co.uk |
>     /V\     |----------------------| www.tomgilbert.freeserve.co.uk |
>    // \\    | Sites I recommend:   `--------------------------------|
>   /(   )\   | www.freshmeat.net www.enlightenment.org www.gnome.org |
>    ^^-^^    `-------------------------------------------------------'
> 
> 
> -- 
> To unsubscribe: mail gnome-devel-list-request@gnome.org with "unsubscribe"
> as the Subject.
>