Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Terminating an embedded interpreter

Reply
Thread Tools

Terminating an embedded interpreter

 
 
Ulrich Eckhardt
Guest
Posts: n/a
 
      09-12-2011
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

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

 
Reply With Quote
 
 
 
 
Chris Angelico
Guest
Posts: n/a
 
      09-12-2011
On Mon, Sep 12, 2011 at 8:00 PM, Ulrich Eckhardt
<(E-Mail Removed)> wrote:
> 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
 
Reply With Quote
 
 
 
 
Steven D'Aprano
Guest
Posts: n/a
 
      09-12-2011
Ulrich Eckhardt wrote:

> 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.



--
Steven

 
Reply With Quote
 
Ulrich Eckhardt
Guest
Posts: n/a
 
      09-12-2011
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

 
Reply With Quote
 
Ulrich Eckhardt
Guest
Posts: n/a
 
      09-12-2011
Chris Angelico wrote:
> 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


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

 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      09-12-2011
On Mon, Sep 12, 2011 at 10:05 PM, Ulrich Eckhardt
<(E-Mail Removed)> wrote:
> Chris Angelico wrote:
>> 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.


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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Python embedded interpreter: how to initialize the interpreter ? ycollet@freesurf.fr Python 3 01-03-2007 01:00 AM
Embedded Python interpreter, runtime libs, and crashing Peter Newman Python 1 10-26-2005 03:38 AM
embedded python and interpreter threads Charlie DeTar Python 2 12-07-2004 04:52 PM
Threads in embedded interpreter doesn't run devrim.erdem@gmail.com Python 3 10-21-2004 07:27 PM
Grabbing stdout From Embedded Interpreter Tim Stanka Python 0 07-19-2004 03:00 PM



Advertisments