[tor-bugs] #7713 [Stem]: Stem should invalidate GETCONF cache
Tor Bug Tracker & Wiki
blackhole at torproject.org
Thu May 30 16:10:33 UTC 2013
#7713: Stem should invalidate GETCONF cache
-----------------------+----------------------------------------------------
Reporter: atagar | Owner: atagar
Type: defect | Status: closed
Priority: minor | Milestone:
Component: Stem | Version:
Resolution: fixed | Keywords: controller easy
Parent: | Points:
Actualpoints: |
-----------------------+----------------------------------------------------
Changes (by atagar):
* status: needs_revision => closed
* resolution: => fixed
Comment:
> The right way to do this would probably be to, umm, lock a lock when
CONF_CHANGED occurs and wait for it to be released in the get_conf call.
Well drats. Thanks for the catch, Ravi!
We can't really lock and await the CONF_CHANGED event since that is
happening in a separate loop. The actual issue here seems to be that we're
using msg() rather than set_conf(). If we used set_conf() then it would be
updating the cache for us, so we could be sure the following get_conf()
would be consistent.
We're probably using msg() on purpose in this test to better simulate what
it is like to have a second controller attached.
Actually, now that I think about it more I'm less concerned that
get_conf() provided the wrong response - if a separate controller makes
asynchronous SETCONF calls then all bets are off. I am, however, concerned
that we got this kind of half-way response. We didn't return either ""
(the old value) or "['abc,xyz,pqrs', 'mno,tuv,wxyz']" (the new value) but
rather a mix of the two because the get_conf() came *between* events.
I suspect the best way for us to handle this is the change I made (which
is to invalidate the cache rather than attempt to update it). If you have
a better idea then let me know!
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7713#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list