LilianMoraru: LilianMoraru: I’ve played in the past with this(when I saw this video of live code patching in Erlang) but I dropped this idea because I came to the conclusion that I cannot make it in a simple way, safe…How do you handle situations like having a pointer into a structure that comes from a shared library and then the structure is modified in the shared library? What happens when you access that data?

TL;DR. I don’t. It is up to the application to handle that.

Long version:

The way it will works is that before the shared library is about to get reloaded the application will get a callback telling it a library is about to get reloaded. It’s up to the application to decide what to do. In my case in ProDBG I will call a function in the library which will serialize it’s state (using an API provided by the application) and then after reload I will call it again with the serialized data so it can restore the state.

Also in the ProDBG case plugins are very self contained. They only talk to the outside by using a messages and the host application only holds one opaque pointer to the instance of each plugin. This pointer is never used by the application itself but only sent in when the instance needs an update.

So this will require that applications using this will need to think about how data is being accessed. Regarding safety shared libraries in Rust are right now always considered unsafe as they call into unknown code.

Despite these issue having ‘live’ change of code this way is nice. This way will never reach something like Common Lisp quality but Common Lisp works very differently from Rust (or C/C++) but still this is much better than nothing.