← Back to team overview

gtg-contributors team mailing list archive

Step to follow to "statify" liblarch

 

This is my intended planning :

1. In filteredtree.py, put a blocking lock for modifying and deleting
functions. Only one of them could be run at the same time. Because of
the __execution_loop, I'm not even sure that it is needed. Maybe
replacing the boolean by a real lock is enough.


2. Modifying function should not modify directly self.cache_nodes and
self.cache_vr but a copy of it. (self.tmp_nodes and self.tmp_vr).  The
self.tmp_* should be copied into self.cache_* at the moment we are
calling the callback.


3. That moment should be atomic, thus wrapped into a blocking lock.


4. All reading method should also acquire that same lock. The tricky
part is for the recursive one.


5. Each time the self.tmp_ are copied into self.cache_, the
self.state_id should be incremented.

6. For each upstream call, liblarch_gtk should also get state_id and
save it.

7.  Each downstream signals from filtered tree should carry the new
state_id. (for modified signals, it's not a new one, as the tree is not
changed).


8. If liblarch_gtk receive a signal with a state_id <= than the
currently saved state_id, the signal is dismissed.




As you can see, only step 4 require some work.





Follow ups