Conversation

Notices

1. Embed this notice
   Rich Felker (dalias@hachyderm.io)'s status on Sunday, 12-May-2024 21:28:07 JST Rich Felker

   in reply to

   • Erin 💽✨

   @erincandescent @ariadne There are basically two reasons folks want dlclose to unload:

   1 is always wrong: they're trying to make it act like a module instance and reset state, rather than having explicit state.

   2 may be reasonable but it's rarely why they care: wanting to repeatedly load new versions of some code without leaking memory.

   • Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Sunday, 12-May-2024 21:28:08 JST Rich Felker

     in reply to

     • Erin 💽✨

     @erincandescent @ariadne Yes. The big problem with the status quo is that, even if you only call dlclose on your own "module like" libs designed to be unloadable safely, they usually have deps on "normal" libs that aren't. But there are also issues with violating dtor order invariants, etc.

   • Embed this notice
     Erin 💽✨ (erincandescent@akko.erincandescent.net)'s status on Sunday, 12-May-2024 21:28:10 JST Erin 💽✨
     @ariadne you can't prove that safety any more than you can prove anything in C
     
     But making it opt in means you can't accidentally unload a library which does not support that.
     
     Last time I talked to dalias that was always his contention about dlclose