4 ms·

> A plugin is only initialized once, and cannot be closed. Why not?

by junke 10y ago

IshKebab 10y ago
I guess it's because if you load a symbol there's no clean way to invalidate it, especially in a thread-safe way. Something like that anyway.
- jerf 10y ago
  I think it's safe to say there is just plain no way to invalidate it. Even if it were hacked together, it would be unusably dangerous for even trivial cases. Module loading is something that can be added to a language later, but I suspect safe module unloading is something that has to go in from day one to ever work right. Even in languages that support it (Erlang) it's got a tricky list of caveats to keep track of that strike me as fairly essential to the problem, rather than accidental (in the Fred Brooks sense of the terms).
pjmlp 10y ago
Because unloading, while possible is a pain to get right. Hence why Java and .NET restrict it to Class Loaders/AppDomains.
- Someone 10y ago
  For those who wonder why: some of the things you have to make sure of are if you want to implement this correctly: - no thread is running code in the plugin. - no thread has a return address on the stack somewhere in the plugin. - no variable stores a pointer pointing into the plugin (This includes objects whose destructor is implemented in the plugin) - no signal handler points into the plugin. - no kernel thread is reading the plug-ins memory. In addition there are race conditions to take care of (e.g. thread T unloads a plugin that thread U is loading) With a 64 bit address space, I guess you can get around most if not all problems by mapping the memory that was mapped to the plugin as "can't read, can't write, can't execute", so that you crash hard if somebody tries to access it, but if you do that, you can just as well keep the code around. Go is garbage-collected, so it likely already has a lot of the logic to do this, but even then, combining the functionality to get a robust implementation of plugin unloading is a lot of work.

> A plugin is only initialized once, and cannot be closed. Why not?

by junke 10y ago

> A plugin is only initialized once, and cannot be closed. Why not?

I guess it's because if you load a symbol there's no clean way to invalidate it, especially in a thread-safe way. Something like that anyway.

jerf 10y ago
I think it's safe to say there is just plain no way to invalidate it. Even if it were hacked together, it would be unusably dangerous for even trivial cases. Module loading is something that can be added to a language later, but I suspect safe module unloading is something that has to go in from day one to ever work right. Even in languages that support it (Erlang) it's got a tricky list of caveats to keep track of that strike me as fairly essential to the problem, rather than accidental (in the Fred Brooks sense of the terms).

pjmlp 10y ago

Because unloading, while possible is a pain to get right. Hence why Java and .NET restrict it to Class Loaders/AppDomains.

Someone 10y ago
For those who wonder why: some of the things you have to make sure of are if you want to implement this correctly: - no thread is running code in the plugin. - no thread has a return address on the stack somewhere in the plugin. - no variable stores a pointer pointing into the plugin (This includes objects whose destructor is implemented in the plugin) - no signal handler points into the plugin. - no kernel thread is reading the plug-ins memory. In addition there are race conditions to take care of (e.g. thread T unloads a plugin that thread U is loading) With a 64 bit address space, I guess you can get around most if not all problems by mapping the memory that was mapped to the plugin as "can't read, can't write, can't execute", so that you crash hard if somebody tries to access it, but if you do that, you can just as well keep the code around. Go is garbage-collected, so it likely already has a lot of the logic to do this, but even then, combining the functionality to get a robust implementation of plugin unloading is a lot of work.