Re: [Gramps-devel] gtk event threading problem, let's design it

[Eero T. <ee...@us...>]

Hi,

On Wednesday 23 January 2008, Benny Malengier wrote:
> Hi, we have some problems with gtk event threading, especially on older
> machines. We need to decide on the design direction we take to solve
> this.
>
> Let me try sketch the problem as I see it.
>
> GTK apparently asynchronously handles X window events behind the scenes.

X and X clients (i.e. Gtk apps) are in separate processes and communicate
through an X client specific socket. 

Gtk doesn't thread by itself (it supports threading applications, but
locking etc has to be done by the application), it's just that event
delivery from the X server to X clients is asynchronous (it would be really
slow if would be synchronous).  This means that X could be forwarding
a window event to an  when app is sending a destroy request for that window
to the X server. However, AFAIK Xlib or Gtk filter events to windows
(X resources) which are not anymore valid; there's no window matching to
the event, so Gtk really *cannot* forward it to any widget...


> The most common bug as an effect of this was the OK button bug: people
> pressing twice OK, and this leading to the save callback being called
> twice, normally crashing gramps.

This sounds like dialog cleanup is being done in wrong order in the
application; it deletes the dialog window and then still continues
processing things for that. It should remove callbacks for objects before
destrying them, if there are such which are not automatically removed when
the object is destroyed.

The only case when this is not possible (i.e. fault of the application
itself) is when you're managing X resources of *other* processes, like
window manager does for application windows.  (Window manager just has error
traps around stuff accessing resources which life-cycle is managed by other 
processes)


	- Eero