Open Marwes opened 6 years ago
Thanks for the report! I think though that since aribtrary trait objects are contained, I'm not sure this can be unwind safe? Could you also elaborate a bit on why you'd like the reactor to be unwind safe?
Chain of consequences here are.
Need to dispatch futures from an interpreter ->
I need to hold a Reactor
in the interpreter -
The test library I use for some tests catches panics and I pass interpreters across this boundary ->
Need to make the gluon interpreter RefUnwindSafe
(which Remote
is the only part that is not)
Nothing I can't work around locally but if it can be fixed upstream then that is obviously preferably (since I think the types here should all be RefUnwindSafe
, they just don't have the impl).
Ok thanks for the explanation! My point here though is that the reactor isn't unwind safe as it contains arbitrary trait objects, so I don't actually think we can fix this at the Core
layer. That being said I was hoping to be able to help out with the chain of things that led to this, but I'm not so sure now :(
Ah, didn't get that Remote
holds arbitrary trait objects. I suppose that if it were to only hold arbitrary trait objects but not execute any code in them then it could be made RefUnwindSafe
, (As it is right now I think it executes arbitrary objects as well).
Oh sorry I thought this was Core
not Remote
! In that sense I think this should definitely be RefUnwindSafe
most likely (although this may best be tested against tokio-rs/tokio perhaps
Specifically this is because of the use of a
UnsafeCell
inside a long list of types so I am not sure which part exactly needs to implement this (guessing it is theQueue
that would assert that it is safe?).