Run plugins in separate processes

[daurnimator]

In case a plugin crashes.

• a plugin would register for certain events + have a command to run
• processes could be run in a sandbox if desired
• provide irc data on stdin?
• reloading becomes killing the process and restarting

[RyanSquared]

Correct me if I'm wrong, but if a plugin "crashes", won't it be fixed the next time it restarts? Because we pass callbacks (instead of a coroutine to iterate over messages), there shouldn't be a reason for a plugin to be reloaded.

[KellerFuchs]

@RyanSquared What if the callback hangs forever?

[daurnimator]

Correct me if I'm wrong, but if a plugin "crashes", won't it be fixed the next time it restarts?

Define "crashes". ==> plugin reload would kill + reap the old process (if it's already dead then it can skip the killing and go straight to reaping) before starting the new process.

[RyanSquared]

@KellerFuchs what if the plugin hangs forever? With the system we have now, the requests are made asynchronously, I believe with a hardcoded timeout.

@daurnimator, I'm asking you to define "crashes":

In case a plugin crashes.

[daurnimator]

With the system we have now, the requests are made asynchronously, I believe with a hardcoded timeout.

No timeout.

@daurnimator, I'm asking you to define "crashes":

"crash" meaning any hang, error or actual crash (e.g. a segfault in a C library)
In the current form errors are not caught in plugins; nor are they monitored for hangs/loops/etc. This makes it very un-resilient.

[RyanSquared]

Does lua-http have timeouts? If so, that could help with that issue. As for errors, I can probably write something to handle that as well. With segfaults, I think there might be a more important issue if a plugin segfaults.

[daurnimator]

Does lua-http have timeouts?

It does. but you have to remember to use them :p

Moving each plugin to it's own process eliminates a whole class of issues.