zesterer
`UnwindSafe` and `RefUnwindSafe` Regarding the channel
I tried to use it as and substitute to mpsc of tokio and found Sender of the Flume is not marked as UnwindSafe and RefUnwindSafe.
When one tries to use this kind of channel for serious application it often matters.
I can see tokio mpsc is only recently marked as UnwindSafe and RefUnwindSafe.
Here are some of the related issues
- Enumerate types which are !UnwindSafe on purpose, fix the rest #4657
- Mark some more types as UnwindSafe #6783
I can see the the root of unsafeness is also the Waker part, namely this line
I see case is quite same with tokio, but not absolutely sure.
@zesterer, how do you think about marking it as UnwindSafe and RefUnwindSafe?
Can anyone see any problem when marking it as so?
I've not looked too closely at the specific requirements of the traits, but I can't imagine anything specific about Flume's implementation that would disallow their implementation, especially for the sync side of the API. Feel free to open a PR!
Thank you for the fast reply.
Indeed the concern is regarding the async situation, as it's around the Waker.
Let me investigate a bit more about the Mutex of "spin" before making the PR.