3 ms·
> Unlike dlopen-based plugin systems, threadprocs run traditional executables with a `main()` function. Why not dlopen with something that calls plugin_main()
by Retr0id 7mo ago
> Unlike dlopen-based plugin systems, threadprocs run traditional executables with a `main()` function.
Why not dlopen with something that calls plugin_main() (etc.) in its own thread?
- jer-irl 7mo agoGood call-out, and I think that's a more practical approach for most systems. For this project, one of my goals was to impose the fewest dependencies possible on the loaded executables, and give the illusion that they're running in a fully independent process, with their own stdin/out/err and global runtime resources. "./my_prog abc" -> "launcher s.sock ./my_prog abc" There's a rich design space if you impose "compile as .so with well-known entry point," and certainly that's what I'd explore for production apps that need this sort of a model.
- fc417fc802 7mo agoWhat if you're trying to run multiple instances of something that uses global state? Or that uses an incompatible library version? (I guess those are technically the same thing.)
- Retr0id 7mo agoGood point! (another reason not to use global state heh)