2 ms·
There's actually pretty simple solution to the loading/unloading problem if you can assume that function signatures do not change. Just generate a wrapper funct
by slaymaker1907 4y ago
There's actually pretty simple solution to the loading/unloading problem if you can assume that function signatures do not change. Just generate a wrapper function which has a R/W lock and then just calls the actual implementation while holding a R lock. To update the implementation, acquire a W lock and replace the implementation.
There is overhead, but I don't think it would be too bad. You could also probably reduce the overhead by doing something fancier like having the daemon inspect the stack frames of other threads (which is expensive, but presumably updates are extremely rare compared to calling functions).
- KerrAvon 4y agoIt's not (just) a low-level synchronization problem, though; it's a larger structural problem. Simple example: If someone has a reference to your function that free()s some pointer, and your function has been replaced with an inert no-op, that pointer is no longer freed when it should be, and you have a memory leak. Extrapolate this to more complex code. Put another way, assume that you solve low-level threadsafety/data race issues. You still have to design the library from the start to be unloadable; you can't unload code that isn't expecting to be unloaded without undesirable side effects.
- slaymaker1907 4y agoYou typically wouldn't replace a function with a no-op since changing who allocs/frees memory is almost certainly an API change which I never claimed my solution would support. The thing my solution would be useful for is for fixing small errors that are tedious to go through a whole compile cycle for. It would be a replacement for modifying values directly in the debugger to try and fix issues (to see if the fix works) and not turn C++ into LISP.