I just tried it by modifying the example code of sandkiste_lua
, and I can confirm how it unwinds through the C functions on my system.
So I read this as:
- There is currently no practical problem if I don't add a
catch_unwind
myself.
- It's believed to be guaranteed at some point to be no problem in the future, but that's no guarantee yet.
I think in practice I have no problem in my original case anyway, because no reasonable implementation of the unsafe
method mmtkvdb::Storable::cmp_bytes_unchecked
(which is what I invoke in my callback) would allocate or ever have to report an error.
I guess I could add to its "Safety" section a requirement that implementors must ensure that the method doesn't panic, but it's not really a practical issue I guess (both because it's not UB in practice to panic and because it's very unlikely any implementation would ever want to panic). But I'll think about that. I would like to avoid adding an extra, unnecessary catch_unwind
, especially if such a "catch" is later added by Rust anyway.
The above case of sandkiste_lua::LuaMachine::callback
, however, is much more likely to panic in practice.
Thanks a lot for your feedback and advice/info.
Regarding what I wrote here:
I guess that's entirely unrelated. This is what !UnwindSafe
is for, so I don't use any values which are in a weird state because of unwinding (except in Drop
handlers, which must be prepared for such a case).
Update:
… but what happens if my drop handlers try to clean up an LMDB environment after I longjmp
ed through it?
Maybe LMDB is not prepared to be cleaned up (e.g. using mdb_env_close
) in that case and will crash badly.
So perhaps I should tackle that issue and add proper "Safety" requirements that forbid panickingunwinding, so I don't have that problem.
Also, if I understand it right, safe code can always ignore the fact that some value ends up in a bad way, e.g. by using AssertUnwindSafe
, so I must ensure myself that I properly "poison" such a value (or abort on panic).