Re: gtk & threads

[bob cs csoft net]

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.

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.

> 
> See:
>     http://www.gtk.org/rdp/glib/glib-threads.html
>     http://www.gtk.org/rdp/gdk/gdk-threads.html
>

Thanks, Ill read through them.
 
> For more info. They're better at this stuff than me...
> 
> > I am trying to figure out how to get past gtk's "cant refresh while in a
> > function" problem.
> > Using threads, I think, would be the best way around it, but I dont see
> > anything on gtk.org about thread safety.
> 
> Threads are one way around this, there are others.
> Timeouts are nice for keeping the frontend up-to-date, or you could
> just do something like 
> if(gtk_events_pending())
>    gtk_main_iteration();

Tryed it. Takes alot of code to do something that sould be done
automaticly. Also dosnt allow you to press a second button while the first
is runng

> (I don't have the code in front of me right now, but its real close to
> this). This is clean for simple situations only though IMO.
> 
> If it suits your application, you could even separate the frontend
> completely from the data engine (not necessarily by threads, you could
> spawn a separate process for this, send it data, and have the results
> refreshed into the display. I quite like this for some things, as you
> can kill the process cold if the user cancels some action, or chooses
> to do something else... I was going to implement this eventually in my
> scrabble game some day...)
> 
> 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.
>