Crates.io | thread-lock |
lib.rs | thread-lock |
version | 0.1.0 |
source | src |
created_at | 2024-01-30 03:58:58.666085 |
updated_at | 2024-01-30 03:58:58.666085 |
description | A wrapper that locks non-Send and non-Sync data to a specific thread |
homepage | |
repository | https://github.com/Aegrithas/thread-lock |
max_upload_size | |
id | 1119806 |
size | 23,468 |
This crate introduces the niche ThreadLock
struct.
This struct stores arbitrary data, but only allows access to it from a specific thread at runtime; in exchange, the ThreadLock
itself is Send
and Sync
.
This has very limited usage, but occasionally it may be useful for cases where some parts of a struct must be multithreaded, while other parts cannot be.
Often, these should be split into distinct structs (one of which is Sync
while the other is not), but this may occasionally be a simpler option.
A (contrived) example similar to an actual usage I had:
struct A; // A: Sync
struct B;
impl !Sync for B {}
pub struct AB {
a: A,
b: ThreadLock<B>
}
impl AB {
pub fn new() -> Self {
let (a, b): (A, B) = construct_ab();
Self { a, b: ThreadLock::new(b) }
}
pub fn foo(&self) { // any thread is allowed to call AB::foo
do_something_with_a(&self.a);
}
pub fn foo_and_bar(&self) {
let b = self.b.try_get().expect("foo_and_bar is only allowed on the same thread that AB was constructed");
do_something_with_a(&self.a);
do_something_with_b(b);
}
}
The notable features of this example:
AB
can do on all threads, so I want AB
to be Sync
.foo_and_bar
) require AB
to have resources (namely, B
) that cannot be shared among threads, as well as the multi-threaded resources.A
and B
can only be constructed together; this is less important, but it can make it harder or less ergonomic to split AB
into distinct structs.