[Retr0id]

> 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]

Good 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]

What 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]

Good point! (another reason not to use global state heh)