Terminating an embedded interpreter

[Ulrich Eckhardt]

Steven D'Aprano wrote:
> Ulrich Eckhardt wrote:
>> I'm trying to provide some scripting capabilities to a program. For that,
>> I'm embedding a Python interpreter, running a script in a separate thread
>> to decouple it from the UI.
>> 
>> Now, how should I handle rogue scripts? For example, when a script hangs
>> in an endless loop, how do I signal the Python interpreter to shut down?
> 
> If you are using threads, they all run within the same Python process. You
> can ask a thread to shut down, but you can't force it to from the outside.
> If the thread runs a script that goes rogue, the script may never return
> control to the thread long enough for it to respond to your request.

Sorry, I described badly what I was doing. The program itself is written in 
C++ and I'm running the Python interpreter in a thread separate to the UI, 
just in order to not hang the UI if anything in the interpreter blocks for 
extended amounts of time. I know that a Python thread is not a "system" 
thread but handled and scheduled internally by Python.


> The main UI loop can still kill itself, and take all the threads with it,
> by calling sys.exit. Or if you really need to, os.abort or os._exit can be
> used for immediate "terminate yourself NOW!!!" commands. (But read the
> docs for them first.)

> A better way may be to run the script in a separate process. You can kill
> the process the same way you would any other rogue process: by sending it
> a signal. See the os and subprocess modules.

Yes, a separate process would be much cleaner, but it would complicate 
communication back to the parent process. The Python code is supposed to 
call a few functions I exported. I'd have to tunnel these calls through 
stdin/stdout/stderr and that is more than what I'm willing to do at the 
moment. It does sound intriguing though, since that would allow me to embed 
any scripting language, not just Python.


> But Python's sandboxing abilities are not great. If you really fear rogue,
> or malicious, scripts, perhaps Python is not the right language for this
> task. Otherwise, just trust the script to be sane.

I'm not fearing malicious scripts. I'm also not concerned about rare hangs 
since this in an internal tool. In this case, I'd take a simple 99% solution 
over a complex 100% solution.


Thank you for your thoughts, Steven!

Uli

-- 
Domino Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932