Killing a thread

[Evan Simpson]

This makes me wonder; Zope has a similar problem, which it mostly handles
with severe restrictions on what's available to the user (no 'while', only
'for', and no '[x]range' to generate arbitrarily large tuples).
Nevertheless, a creative malcontent could consume a lot of resources with
nested loops.

Bytecodehacks to the rescue?  <waves hands furiously> Wrap the user code in
a function (if it isn't already), find all jump-back codes, and insert a bit
of test code in front of them which bails out if ?a global variable is set?
(not sure what's best, here).  You'll take a slight performance hit, but
that probably won't matter in this context.  Perhaps you could inline a call
to time.clock and use it to limit the running time of the function.

Donn Cave <donn at u.washington.edu> wrote in message
news:7mvml3$u5k$1 at nntp6.u.washington.edu...
catlee at my-deja.com writes:
| I'm writing a progrma where some user code is executed in a restricted
| environment running in a separate thread.  Now, if the user is
| malicious, s/he can just put 'while 1: 1+1'.  I'd like to be able to
| recover from this.  Is there any way I can kill the thread that is stuck
| in the infinite loop?