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 _______________________________________________ Mailing list: https://launchpad.net/~gtg-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-contributors More help : https://help.launchpad.net/ListHelp
