Question

In my application which runs user submitted code[1] in separate threads, there might be some cases where the code might take very long to run or it might even have an infinite loop! In that case how do I stop that particular thread?

I’m not in control of the user code, so I cannot check for Thread.interrupted() from the inside. Nor can I use Thread.stop() carelessly. I also cannot put those code in separate processes.

So, is there anyway to handle this situation?

[1] I’m using JRuby, and the user code is in ruby.

Answer 1

With the constraints you’ve provided:

1. User submitted code you have no control over.
2. Cannot force checks for Thread.interrupted().
3. Cannot use Thread.stop().
4. Cannot put the user code in a process jail.

The answer to your question is “no, there is no way of handling this situation”. You’ve pretty much systematically designed things so that you have zero control over untrusted third-party code. This is … a suboptimal design.

If you want to be able to handle anything, you’re going to have to relax one (or preferably more!) of the above constraints.

---

Edited to add:

There might be a way around this for you without forcing your clients to change code if that is a(nother) constraint. Launch the Ruby code in another process and use some form of IPC mechanism to do interaction with your main code base. To avoid forcing the Ruby code to suddenly have to be coded to use explicit IPC, drop in a set of proxy objects for your API that do the IPC behind the scenes which themselves call proxy objects in your own server. That way your client code is given the illusion of working inside your server while you jail that code in its own process (which you can ultimately kill -9 as the ultimate sanction should it come to that).

Later you’re going to want to wean your clients from the illusion since IPC and native calls are very different and hiding that behind a proxy can be evil, but it’s a stopgap you can use while you deprecate APIs and move your clients over to the new APIs.