Re: callbacks and locking

[Hugo Hallqvist <hugha495 student liu se>]

> I think you can do this. But its usefull only if you're doing long 
> processing
> in *routine()* and wish another threads be able to use gtk stuff 
> this time.

Ok, so gtk doesn't need to hold gdk_threads lock over the whole callback, nice.

> > gdk_threads_enter();
> >
> > return;
> >
> > }
> >
> > where X is
> Hmm, X==routine() ? If so, the leave/enter is useless cause you run it
> in one thread and lock (enter) occurs almost after the unlock (leave).
>
> > void X() {
> > lock_stuff();
> > gdk_threads_enter();
> > touch_gui_components();
> > gdk_threads_leave()
> > unlock_stuff();
> > return;
> > }


No X is not a routine.

Really, I should probably have been more clear about this.

Routine X is an abstraction-routine saying to another thread, that he should do this and that. Routine X then 
waits for thread to do his stuff.  The thread then locks a few thing and updates gui, requiring gdk-lock, and 
when it's done it passes a message to routine X that it is done. Routine X then exits and passes control to 
callback.

It works kind of as of now when using this scheme, the problem i've got is that I mess up something in gtk, I 
don't get a hang/deadlock but gtk freezes after this is done, when showing a popup menu newly created by the 
thread that routine X passed message to.

I should say that I'm quite confident that this is not an locking issue. All calls to gtk-stuff from other 
threads are surrounded with gdk_threads_enter/leave. However maybe I should consider redesigning the whole 
thing and have a dedicated thread that just receives messages from thread that wants to update gui. However, 
it adds complexity and removes convenience, so I rather get my current way to work.

Hope this clear things up a bit.

Anyway, thanks for your answer.

Regards,

//Hugo Hallqvist