mirrors/arti.git/crates/tor-rtmock/src, branch arti-v1.4.4 mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.4.4 2025-05-16T01:46:11Z *: use std::io::Error::other in many places 2025-05-16T01:46:11Z Nick Mathewson nickm@torproject.org 2025-05-16T01:46:11Z urn:sha1:30617ad94bed7d2e4829c10144daf202d3ffd23c The `IoError::other` function is an easier way to say `IoError::new(IoErrorKind::Other, ...)`. It's been around since 1.74, but clippy started warning about the more verbose version in 1.87. rtmock: use Option::replace instead of mem::replace 2025-05-16T01:39:48Z Nick Mathewson nickm@torproject.org 2025-05-16T01:39:48Z urn:sha1:9aa5137a79ea9af627135d088468998a208cddbb Option::replace has been around since 1.31, but the clippy warning is new. tor-rtcompat: task tests: Allow a clippy lint 2025-04-10T16:22:19Z Ian Jackson ijackson@chiark.greenend.org.uk 2025-04-10T16:22:07Z urn:sha1:7fc0ec4f2161e1023a2243e207879d2dbd5c754d This doesn't seem to happen with my local compiler. Anyway, suppress it. I don't think we want to split up this function. tor-rtcompat: task: Break out subthread_yield 2025-04-10T14:34:34Z Ian Jackson ijackson@chiark.greenend.org.uk 2025-04-10T14:34:04Z urn:sha1:cedb3da4588b96eae0d6750f10fe43dd4d504a63 This gets rid of a clippy complaint about subthread_block_on_future being too complicated. tor-rtcompat: task tests: Allow a clippy lint 2025-04-10T14:34:34Z Ian Jackson ijackson@chiark.greenend.org.uk 2025-04-10T14:26:39Z urn:sha1:c71aa81d5287531421adb2175ad68ef524d76d3b tor-rtcompat: BlockOn: relax bounds on reenter_block_on 2025-04-09T16:52:03Z Ian Jackson ijackson@chiark.greenend.org.uk 2025-04-07T16:58:45Z urn:sha1:2a7dc6c46274e0d96e773c031cabd5373483429e The future no longer needs to be `Send + 'static`. tor-rtmock: task: subthread_block_on_future; Yield a bit more 2025-04-09T16:52:03Z Ian Jackson ijackson@chiark.greenend.org.uk 2025-04-09T16:20:16Z urn:sha1:a56e724360f6c1e33e892970b88f651296e79af7 tor-rtmock: task tests: New subhtread_pingpong test 2025-04-09T16:52:03Z Ian Jackson ijackson@chiark.greenend.org.uk 2025-04-09T15:39:09Z urn:sha1:eadb6e980fe2b8acc8d6ea3b1ea8d7c8aa2cc188 This test demonstrates that the intended use pattern compiles and works. It couldn't exist until now because we couldn't conveniently make a `Send + 'static` future out of `rx.next()`. tor-rtmock: task: Redo subthread_block_on_future; poll on the subthread (fmt) 2025-04-09T16:52:03Z Ian Jackson ijackson@chiark.greenend.org.uk 2025-04-09T16:42:38Z urn:sha1:7b98a7de906c02701b9131d65c465b01094497bd tor-rtmock: task: Redo subthread_block_on_future; poll on the subthread 2025-04-09T16:51:54Z Ian Jackson ijackson@chiark.greenend.org.uk 2025-04-09T16:22:30Z urn:sha1:f0f1bb3eade8dcafdbb97b831b8a21beaee0ba56 Previously we put the future into the data structure, had the exeuctor poll it there, and only woke up the subthread when the future was ready. Now, instead, we put a new TaskFutureInfo variant into the data structure, and the executor context switches to the subthread every time. Then we poll the future on the subthread. Moving the future into the data structure meant we had to do use a proxy future to store the return value. Now that's not needed any more. Now the future doesn't need to be Send + 'static. Fixes #1933.