Terminating an embedded interpreter

[Ulrich Eckhardt]

Hi!

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? In
other words, I want to trigger something like what Control-C does in a
"normal" environment.

In case it matters, the OS here is MS Windows.

Thanks!

Uli

 

[Chris Angelico]

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? In
other words, I want to trigger something like what Control-C does in a
"normal" environment.

You can use PyErr_SetInterrupt to raise KeyboardInterrupt, but it can
be caught by the script. There's no guaranteed way, short of killing
the process.

ChrisA

 

[Steven D'Aprano]

Hi!

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.

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.

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.

 

[Ulrich Eckhardt]

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

 

[Ulrich Eckhardt]

You can use PyErr_SetInterrupt to raise KeyboardInterrupt

This sounds useful. Just to make sure, this would be called from a different
thread than the one running the Python script, is that still OK?

, but it can be caught by the script. There's no guaranteed way,
short of killing the process.

This will do for my plans, I'm not trying to defend against anything
malicious.


Thanks you!

Uli

 

[Chris Angelico]

This sounds useful. Just to make sure, this would be called from a different
thread than the one running the Python script, is that still OK?


This will do for my plans, I'm not trying to defend against anything
malicious.

Yes, that would be what you want then. The main thing to take care of
is a blanket 'except' that doesn't specify what it's accepting - it'll
snarf the KeyboardInterrupt and carry on its merry way.

ChrisA