mirrors/arti.git/crates/arti-client/src/builder.rs, branch arti-v1.2.7 mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.2.7 2024-08-28T16:47:22Z arti-client: Document the unspecified behavior of create_inert(). 2024-08-28T16:47:22Z Gabriela Moldovan gabi@torproject.org 2024-08-28T13:26:28Z urn:sha1:8e6dfc5703b1947ab7b87719f25879da30f75670 Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2370#note_3066621 arti-client: Add an InertTorClient for accessing client state (fmt). 2024-08-28T16:47:22Z Gabriela Moldovan gabi@torproject.org 2024-08-27T14:20:16Z urn:sha1:aa72f0c59e17f939d16c6fc4663df21fdb00c2dc arti-client: Add an InertTorClient for accessing client state. 2024-08-28T16:47:22Z Gabriela Moldovan gabi@torproject.org 2024-08-27T14:16:01Z urn:sha1:d99be523d4a0237c19ae3a25c24f0481934f51ef Implements the `TorClientThatIsntRunning` mentioned in !2314 (see also `doc/dev/notes/keymgr-porcelain.md`), except `TorClientThatIsntRunning` is called `InertTorClient`. This commit is mostly code motion: I've moved the `create_keymgr` function and the impls of `generate_service_discovery_key` and `get_service_discovery_key` from `TorClient` to `InertTorClient`. The `InertTorClient` advertises itself as a handle for accessing the keystores and other persistent state, but it currently only has 2 functions (`generate_service_discovery_key` and `get_service_discovery_key`). I expect it will grow additional functionality in the future. Resolve a rustdoc warning. 2024-06-24T13:30:32Z Nick Mathewson nickm@torproject.org 2024-06-24T13:29:36Z urn:sha1:197a0976fdc344ae9a5f161129854f0ca457d681 Add a maximum to local_resource_timeout. 2024-06-24T12:41:09Z Nick Mathewson nickm@torproject.org 2024-06-18T14:01:26Z urn:sha1:c3f967dbe101e3d6cda88cff56df6ae7954c54ad local_resource_timeout: Change wait interval to 50 ms. 2024-06-24T12:41:09Z Nick Mathewson nickm@torproject.org 2024-06-12T19:18:10Z urn:sha1:3ed129965a893a6c544ea0ed42852031f0a9ce3c Rename fslock_timeout to local_resource_timeout 2024-06-24T12:41:09Z Nick Mathewson nickm@torproject.org 2024-06-12T19:16:34Z urn:sha1:da9526e2128c317c61dc7fd4098a9144659445b8 Name chosen to match the error kind that we're detecting. Clarify documentation about blocking. 2024-06-24T12:41:09Z Nick Mathewson nickm@torproject.org 2024-06-12T19:04:14Z urn:sha1:5b808e5e0d38f5c3c48af5b2bd1456d0764ddd2e TorClientBuilder: Wait for a little while if the lockfiles are held. 2024-06-24T12:41:09Z Nick Mathewson nickm@torproject.org 2024-06-11T14:56:49Z urn:sha1:6fd5145762d9fb74f4b2fd6b48ad0ac4eb530087 This commit adds a parameter to TorClientBuilder that control how long we should retry constructing a TorClient if we get a LocalResourceInUse error. When this parameter is not set, we default to 500 milliseconds for async entry points and 0 milliseconds for sync entry points. (`LocalResourceInUse` usually means that a lockfile is held by somebody else; but when the resource is some other type, we typically want the same behavior anyway.) (I really don't want to introduce delays by default for the create_unbootstrapped case, since it previously had no delay at all.) There is now also an async entry point to create an unbootstrapped TorClient. Closes #1464. TorClientBuilder: take self by reference when building 2024-06-24T12:41:09Z Nick Mathewson nickm@torproject.org 2024-06-11T14:27:23Z urn:sha1:b71afdeca631c5a889f0bd27cd02ee3b83f45bdd There is no actual reason to consume this type, and taking it by reference allows us to retry.