mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.3.0 2022-04-07T15:33:34Z 2022-04-07T15:33:34Z Nick Mathewson nickm@torproject.org 2022-04-07T15:30:08Z urn:sha1:99146da2c2654c01259b8219bd491c5d4ac47039 (It is not yet actually used.) 2022-04-07T14:47:45Z Nick Mathewson nickm@torproject.org 2022-04-06T13:05:35Z urn:sha1:c3c43b088e9f8dcbe876c277c3af14705244e8b0 (The information is not yet recorded.) 2021-11-02T15:19:57Z Nick Mathewson nickm@torproject.org 2021-11-02T15:19:57Z urn:sha1:453855693b1d53a26fa8315f6d29a97b04cf8485 This is based on @eta's patches for !118 and !119: Since we already have an unbounded channel, we don't need to use an elaborate mess of one-shot senders. We can just use the unbounded_send() method, which also lets us enqueue a message without having to await. Closes #219. 2021-10-29T12:39:04Z Nick Mathewson nickm@torproject.org 2021-10-29T12:39:04Z urn:sha1:1ee24ce6537373448d8fd5fb074768c6887cb90b Instead of putting a fully qualified name in the text, in most cases we should just use the short name of the type or function we're referring to. In other words, instead of saying [`crate::module::Foo`], we should typically say [`Foo`](crate::module::Foo). 2021-10-13T14:55:44Z Nick Mathewson nickm@torproject.org 2021-10-13T14:55:44Z urn:sha1:e625b2cff5f3f1c04ecaa026c46c0ea82e824b1a 2021-10-10T16:08:31Z Nick Mathewson nickm@torproject.org 2021-10-10T16:08:31Z urn:sha1:34c10feae40d9b0822478e24f01d804e5576b59e The advantage here is that we no longer have to use a futures-aware Mutex, or a blocking send operation, and therefore can simplify a bunch of the GuardMgr APIs to no longer be async. That'll avoid having to propagate the asyncness up the stack. The disadvantage is that unbounded channels are just that: nothing in the channel prevents us from overfilling it. Fortunately, the process that consumes from the channel shouldn't block much, and the channel only gets filled when we're planning a circuit path. 2021-10-07T16:09:29Z Nick Mathewson nickm@torproject.org 2021-10-06T21:19:32Z urn:sha1:00acc5c5b80ed000f14376734f41afb819bd27c4 Also, refactor our message handling to be more like the tor_proto reactors. The previous code had a bug where, once the stream of events was exhausted, we wouldn't actually get any more notifications. 2021-10-07T14:45:42Z Nick Mathewson nickm@torproject.org 2021-09-10T15:18:24Z urn:sha1:0779923d6474bb72427d19b2e504b3fd370b78a2 There are some missing parts here (like persistence and tests) and some incorrect parts (I am 90% sure that the "exploratory circuit" flag is bogus). Also it is not integrated with the circuit manager code.