gtg-contributors team mailing list archive

[Lionel Dricot <ploum@xxxxxxxxx>]

Hi everyone (and especially Luca, as this mail is mostly for you),

Regarding the no_crash branch, I took some time to think instead of
coding. 


I think that currently we have two kind of crashes :
- Those caused by the gtk.stuffs being accessed by another thread than
the mainloop. (this is explicitly forbidden but, unfortunately, not
enforced).
- Those caused by a liblarch.ViewTree being updated by multiple threads
at the same time, thus having an inconsistent state during that update
(I don't know whether or not this inconsistent state persists after both
threads exit). 


Thus:

1. The whole liblarch_gtk should be in the gtk.mainloop thread. This is
already the case except for the four callbacks called by
liblarch.ViewTree : add, delete, modify, reorder.

I believe that a way to call a function in the mainloop is to call it
with gobject.iddle_add (to be confirmed).

Thus, I think that enabling TM_IDLE_ADD in the treemodel.py should be
enough to ensure that the whole liblarch_gtk is well in the
gtk.mainloop.


We might also check the TM_USE_SIGNALS. I'm not sure about this because
I was thinking that signals, in that context, were just like simple
callbacks and that the signal receiver would be run in the caller
thread.



2. Regarding the ViewTree thread protection, it will be a bit trickier
but not so much. 

There's two kind of method there : those updating the viewtree and those
trying to get information about the current state.

Those two kind of method should be fairly separated and identified right
now. What I propose is the following :

- Only one modifying method could be run at once (with a lock). It more
or less already the case but we should use a proper lock, not a simple
boolean.

- Modifying methods write the new state in a temporary set of variables.

- When it's done, the methods take a global lock, copy the temporary set
into the real description set, release the signals, release the lock.
(maybe should we release before sending the signal ?)

- Reading methods read the real set but block on the global lock (but we
know that it would be short because it's just a matter of putting a
variable into another).



What do you think ? Will it ensure that the whole liblarch is
thread-safe ? (which is a huge feature !).  Do you think it would be
possible to write unit tests to ensure thread safety ?


Lionel