UnwindSafe + RefUnwindSafe #32
Comments
|
We don't implement these traits because the Since the lock doesn't get poisoned by unwinding, we can't claim to be unwind-safe. However you can avoid the need for this trait by using AssertUnwindSafe from the standard library. |
4 tasks
2 tasks
ltratt
added a commit
to ltratt/yk
that referenced
this issue
Apr 2, 2021
Jobs for the worker queue are simply `Send`able functions, since they are likely to be run on another thread. Our queue is incredibly simplistic as is our model of worker threads. Every time a new job is pushed, we create another worker thread, until we've reached the maximum number of available worker threads. Worker threads then spin endlessly waiting for work to do. Worker threads never die, nor do they yield to other threads. Note that we have to use the standard library's `Mutex` rather than parking_lot's because the latter is not `UnwindSafe` (see Amanieu/parking_lot#32) and our current use of `catch_unwind` requires that.
ltratt
added a commit
to ltratt/yk
that referenced
this issue
Apr 6, 2021
Jobs for the worker queue are simply `Send`able functions, since they are likely to be run on another thread. Our queue is incredibly simplistic as is our model of worker threads. Every time a new job is pushed, we create another worker thread, until we've reached the maximum number of available worker threads. Worker threads then spin endlessly waiting for work to do. Worker threads never die, nor do they yield to other threads. Note that we have to use the standard library's `Mutex` rather than parking_lot's because the latter is not `UnwindSafe` (see Amanieu/parking_lot#32) and our current use of `catch_unwind` requires that.
aschey
added a commit
to aschey/stream-download-rs
that referenced
this issue
Dec 8, 2024
`parking_lot`'s synchronization primitives [aren't unwind safe](Amanieu/parking_lot#32) which can make it tricky to use the `StreamDownload` struct with FFI. However, we can use `AssertUnwindSafe` to manually mark these as safe because we should never panic while holding a mutex (if we do, that's a separate bug that should be addressed).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
I apologize in advance for a question which might seem basic:
The standard library
Mutextype implements UnwindSafe + RefUnwindSafe:However, the implementation in a
parking_lotdoesn't.The understanding of both implementations currently a bit out of my depth, but would it be practical (or even possible, for that matter) to lift those restrictions (implement the traits) for
parking_lot::Mutex?I encountered this problem, when the library I was writing against bumped it's major API to require those trait bounds, and my code was already using the
parking_lot.The text was updated successfully, but these errors were encountered: