3 ms·

Apart from most perf critical cases, it's a good idea to run plugins in a separate process anyway. This way a bad plugin won't crash or corrupt your own process

by pornel 4y ago

Apart from most perf critical cases, it's a good idea to run plugins in a separate process anyway. This way a bad plugin won't crash or corrupt your own process. You will be able to stop and unload it without risk of leaving locks locked or thread-locals leaking. And also there's WASM now which has even better sandboxing and OS/architecture independence.

pjmlp 4y ago
WASM is nothing new, just a recyling of old ideas with refueled marketing.
- Ygg2 4y ago
  Doesn't it work on all platforms? In theory, at least?
  - pjmlp 4y ago
    Like plenty of other bytecode formats that predated it.
    - malkia 4y ago
      And good luck debugging / make it performant and still not clear how well the memory allocation is handled (in the dll-host situation, often the plugin may use the alloc/free functionality from the host, and give hints, in wasm case - this would be a bit of sandbox)
- pornel 4y ago
  Something existing and succeeding is not automatically a claim that it's the only one possible thing, or even a novel idea, so dismissal "it's just recycling old ideas" is non-sequitur. I'm not even sure what you're trying to say with this comment. Is only 1958 LISP or maybe SmallTalk worthy and truly novel, and every other technology must come with a disclaimer that it's just a pale imitation and everything has been done before? Maybe there was some underappreciated pioneer PL/BYTECODE-1968, but in 2023 there's WASM, CIL, Java bytecode (with marketing as large as the dotcom bubble), maybe Lua or eBPF. For practical application it absolutely doesn't matter which one was first or the most humble. What matters is that WASM is common popular standard now. It has easy to embed runtimes and decent language support. The marketing around it is a huge plus too, because I can tell people "use WASM" and it'll be cool and they'll use it, instead of e.g. instinctively reacting "ewwww, Java".
mike_hearn 4y ago
Note that this is how things were done before dynamic linking was invented, and dynamic linking was seen as a big step forward. Processes+shared memory is a really painful and slow paradigm compared to just invoking function calls on the same stack and in the same process. "a bad plugin won't crash or corrupt your own process." It still can. The plugin just has to return bad data you're not prepared to handle, or crash in a way you didn't anticipate and code around. And note that with higher level languages the whole thing is moot. A plugin crashing just means it throws an exception which can be caught, reported and quite likely the host process will survive just fine even though it's all in-process and dynamically loaded.

by pornel 4y ago

pjmlp 4y ago

WASM is nothing new, just a recyling of old ideas with refueled marketing.

Ygg2 4y ago
Doesn't it work on all platforms? In theory, at least?
- pjmlp 4y ago
  Like plenty of other bytecode formats that predated it.
  - malkia 4y ago
    And good luck debugging / make it performant and still not clear how well the memory allocation is handled (in the dll-host situation, often the plugin may use the alloc/free functionality from the host, and give hints, in wasm case - this would be a bit of sandbox)
pornel 4y ago
Something existing and succeeding is not automatically a claim that it's the only one possible thing, or even a novel idea, so dismissal "it's just recycling old ideas" is non-sequitur. I'm not even sure what you're trying to say with this comment. Is only 1958 LISP or maybe SmallTalk worthy and truly novel, and every other technology must come with a disclaimer that it's just a pale imitation and everything has been done before? Maybe there was some underappreciated pioneer PL/BYTECODE-1968, but in 2023 there's WASM, CIL, Java bytecode (with marketing as large as the dotcom bubble), maybe Lua or eBPF. For practical application it absolutely doesn't matter which one was first or the most humble. What matters is that WASM is common popular standard now. It has easy to embed runtimes and decent language support. The marketing around it is a huge plus too, because I can tell people "use WASM" and it'll be cool and they'll use it, instead of e.g. instinctively reacting "ewwww, Java".

mike_hearn 4y ago

Note that this is how things were done before dynamic linking was invented, and dynamic linking was seen as a big step forward. Processes+shared memory is a really painful and slow paradigm compared to just invoking function calls on the same stack and in the same process. "a bad plugin won't crash or corrupt your own process." It still can. The plugin just has to return bad data you're not prepared to handle, or crash in a way you didn't anticipate and code around. And note that with higher level languages the whole thing is moot. A plugin crashing just means it throws an exception which can be caught, reported and quite likely the host process will survive just fine even though it's all in-process and dynamically loaded.