gtg-contributors team mailing list archive

[Luca Invernizzi <invernizzi.l@xxxxxxxxx>]

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