Hello developers, Tonight I've looked into gtk crashes. It seemed that they were all concurrency issues. Since the interaction with liblarch can come only from two sources (gtg core from the bottom and gtk from the top), I've tried to make those work in a mutual exclusive fashion. Turns out, it works!
In branch lp:~gtg-user/gtg/no-more-crashes you'll find a decorator @synchronized. What it basically does is lock a mutex (that is only one, used by both liblarch and liblarch gtk), blocking functions if the mutex has already been acquired. The lock is at thread level, meaning that if a thread already has acquired the lock, it will acquire it again without problems, while other threads will block (this is great because many liblarch functions are recursive, and locking a standard mutex twice would cause a deadlock - python, which really has *everything*, has that feature built-in in the RLock class). The name of the branch is very optimistic: some crashes still occur from time to time, but it's probably because I haven't decorated every single function (it's 1am, I want to sleep :) ). This will probably make performances a little bit worse, although the speed test gives approximately the same results. Note: Liblarch is still dead slow and ui-freezing with the -s bryce option. It doesn't scale well, but with this approach we might also solve that issue. The basic idea that I'm proposing is to refactor libarch so that: - every gtk access locks a global RLock (easy, already done) - gtg accesses are threaded, but every time the internal tree stucture needs to be changed in any of the views (adding nodes, nodes that do not satisfy filters anymore...), then the same lock must be acquired, and released only once liblarch state is consistent again and the change has been propagated to gtk. So, we should isolate in short functions all the parts of liblarch that change the tree (not the tree class, the tree of tasks created with the relationships). What do you think? Luca _______________________________________________ Mailing list: https://launchpad.net/~gtg-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-contributors More help : https://help.launchpad.net/ListHelp
