<feed xmlns='http://www.w3.org/2005/Atom'>
<title>mirrors/arti.git/crates/tor-circmgr/src/impls.rs, branch arti-v0.0.2</title>
<subtitle>mirror of https://gitlab.torproject.org/tpo/core/arti
</subtitle>
<id>http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.0.2</id>
<link rel='self' href='http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.0.2'/>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/'/>
<updated>2021-10-26T17:01:01Z</updated>
<entry>
<title>Merge remote-tracking branch 'origin/mr/102'</title>
<updated>2021-10-26T17:01:01Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2021-10-26T17:01:01Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=b0fd7cff8e429e95534e0056a5800627a265ddbc'/>
<id>urn:sha1:b0fd7cff8e429e95534e0056a5800627a265ddbc</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Overhaul the way WaitFor and the MockSleepProvider work</title>
<updated>2021-10-26T15:33:23Z</updated>
<author>
<name>eta</name>
<email>tor@eta.st</email>
</author>
<published>2021-10-25T13:19:07Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=e8419abd2579960d59cfe418adc15cdccd20b154'/>
<id>urn:sha1:e8419abd2579960d59cfe418adc15cdccd20b154</id>
<content type='text'>
Instead of racily advancing time forward, this commit attempts to rework
how WaitFor works, such that it makes advances when all sleeper futures
that have been created have been polled (by handing the MockSleepRuntime
a Waker with which to wake up the WaitFor).

The above described mechanics work well enough for the double timeout
test, but fail in the presence of code that spawns asynchronous /
background tasks that must make progress before time is advanced for the
test to work properly. In order to deal with these cases, a set of APIs
are introduced in order to block time from being advanced until some
code has run, and a carveout added in order to permit small advances in
time where required.

(In some cases, code needed to be hacked up a bit in order to be made
properly testable using these APIs; the `MockablePlan` trait included in
here is somewhat unfortunate.)

This should fix arti#149.
</content>
</entry>
<entry>
<title>Fix a typo in a comment.</title>
<updated>2021-10-25T12:25:59Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2021-10-25T12:25:59Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=529d5d5efb880c03177293524913cce81f57b301'/>
<id>urn:sha1:529d5d5efb880c03177293524913cce81f57b301</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Use better reporting for guard status.</title>
<updated>2021-10-13T15:24:37Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2021-10-13T15:24:37Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=f15cde80de0b5f6f81a7426addba35c3c7506112'/>
<id>urn:sha1:f15cde80de0b5f6f81a7426addba35c3c7506112</id>
<content type='text'>
The previous code would report all failures to build a circuit as
failures of the guard.  But of course that's not right:  If we
fail to extend to the second or third hop, that might or might not
be the guard's fault.

Now we use the "pending status" feature of the GuardMonitor type so
that an early failure is attributed to the guard, but a later
failure is attributed as "Indeterminate".  Only a complete circuit
is called a success.  We use a new "GuardStatusHandle" type here so
that we can report the status early if there is a timeout.
</content>
</entry>
<entry>
<title>WIP</title>
<updated>2021-10-11T19:37:59Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2021-10-11T19:37:59Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=ad851c43c64d50b072bbd8bd5f2b959938b09cdd'/>
<id>urn:sha1:ad851c43c64d50b072bbd8bd5f2b959938b09cdd</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Integrate GuardUsability and GuardMonitor into CircuitBuilder.</title>
<updated>2021-10-10T17:48:58Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2021-10-10T17:34:38Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=34b576a8158114eb715616f85155d4b11513b78d'/>
<id>urn:sha1:34b576a8158114eb715616f85155d4b11513b78d</id>
<content type='text'>
(When we're building a path with a guard, we need to tell the guard
manager whether the path succeeded, and we need to wait to hear
whether the guard is usable.)
</content>
</entry>
<entry>
<title>Move all crates into a `crates` subdirectory.</title>
<updated>2021-08-27T13:53:09Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2021-08-27T13:53:09Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=557a0ff40b3731d4690767de27010bbeff08777d'/>
<id>urn:sha1:557a0ff40b3731d4690767de27010bbeff08777d</id>
<content type='text'>
This will cause some pain for now, but now is really the best time
to do this kind of thing.
</content>
</entry>
</feed>
