mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.0.1 2021-10-28T15:44:09Z 2021-10-28T15:44:09Z Nick Mathewson nickm@torproject.org 2021-10-28T15:44:09Z urn:sha1:a730478fd0aee63245891b3bb98181ed9928572a 2021-10-27T20:31:31Z Nick Mathewson nickm@torproject.org 2021-10-27T13:57:43Z urn:sha1:b7c7c8ba13eb15fa351c47e928e240701da19fe6 The previous version of this test used the old, racy version of wait_for (see #149). The new version is refactored so that simulated time is only allowed to advance after each step is done, so that we can actually be sure that each step in the process will happen as it should. In order to get the time-advances to proceed properly, and avoid polluting state between tests, I've had to introduce some machinery to encode the proper amount for time to advance. It isn't something I'd want to use for a whole bunch of tests, but for just one set, it's fine. These tests now pass reliably for me. I wonder if a discrete-event-simulation approach (hello, Shadow) would let us write tests like these to our hearts' content? 2021-10-26T17:13:46Z Nick Mathewson nickm@torproject.org 2021-10-26T17:12:41Z urn:sha1:e64177d97e3623474f042df45efefa46d17a45a0 These are my fault; I merged the wrong version of !102. :p 2021-10-26T17:01:01Z Nick Mathewson nickm@torproject.org 2021-10-26T17:01:01Z urn:sha1:b0fd7cff8e429e95534e0056a5800627a265ddbc 2021-10-26T15:33:23Z eta tor@eta.st 2021-10-25T13:19:07Z urn:sha1:e8419abd2579960d59cfe418adc15cdccd20b154 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. 2021-10-20T17:13:15Z Nick Mathewson nickm@torproject.org 2021-10-20T17:13:15Z urn:sha1:c8cfbda3394b6541deb09e9116cb495587f1318f 2021-10-20T16:06:58Z Nick Mathewson nickm@torproject.org 2021-10-20T16:06:58Z urn:sha1:16ec1d21f2388afe91a66b8b2415c036c3af529e This is a big change, but it does simplify the type of Builder a little, and isolates locking across different (potential) timeout estimator types. 2021-10-19T15:26:22Z Nick Mathewson nickm@torproject.org 2021-10-19T15:26:22Z urn:sha1:89d1fb1767579b2a7cb8b2e15036847c8de5d4f4 We can use this in the case where we don't get the lock on the state file, because another process is running. 2021-10-13T15:24:37Z Nick Mathewson nickm@torproject.org 2021-10-13T15:24:37Z urn:sha1:f15cde80de0b5f6f81a7426addba35c3c7506112 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. 2021-10-10T16:38:50Z Nick Mathewson nickm@torproject.org 2021-10-10T16:38:50Z urn:sha1:33ba697b5d238e0422f0a8c98ac1f16b4c29bf85