gtg-contributors team mailing list archive
-
gtg-contributors team
-
Mailing list archive
-
Message #00471
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