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
- 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
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).
… but what happens if my drop handlers try to clean up an LMDB environment after I
longjmped 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).