embedding: forcing an interpreter to end

P

pdectm

I'm trying to prototype an application which runs multiple python
scripts, each in its own interpreter and OS thread. I've not been able
to forceable stop a script which does not respond to a request to stop.

My thought was to simply call:

PyThreadState_Clear(xxx);
PyThreadState_Delete(xxx); // Fatal Python error: no last thread
Py_EndInterpreter(xxx);

But, this doesn't work. The call to delete causes a fatal error. If I
skip the call to delete, the call to EndInterpreter() ends but seg
faults abound afterwards. A small sample follows.

I've googled my heart out and reread the threading API countless times.
Any suggest or hints would be greatly appreciated.

----
#include "Python.h"

#include <stdio.h>
#include <unistd.h>
#include <pthread.h>

PyThreadState *gtstate;

void * mythread( void *none )
{
PyEval_AcquireLock();
gtstate = Py_NewInterpreter();

PyRun_SimpleString( "import time\nwhile 1:\n\tprint \"I won't
stop\"\n\ttime.sleep(1.0)\n" );

printf( "Interpreter was shutdown ... yeah \n" );

PyEval_ReleaseLock();
}

int main(int argc, char *argv[] )
{
pthread_t thread;
PyThreadState *tstate;

Py_Initialize();
PyEval_InitThreads();
tstate = PyEval_SaveThread();

pthread_create( &thread, (pthread_attr_t *)NULL, mythread, NULL );

sleep(3);

/* Make that pesky script die */
printf( "die ... \n" );
PyEval_AcquireLock();

PyThreadState_Clear(gtstate);
//PyThreadState_Delete(gtstate); // Fatal Python error:
Py_EndInterpreter: not the last thread

PyThreadState_Swap(gtstate);
Py_EndInterpreter(gtstate);

PyEval_ReleaseLock();
sleep(3); // Segmentation fault
PyEval_AcquireThread(tstate);
Py_Finalize();

return(0);
}
 
D

Diez B. Roggisch

Hi,
I've googled my heart out and reread the threading API countless times.
Any suggest or hints would be greatly appreciated.

You might have used the wrong keywords - the subject of killable threads
comes up every month once or twice, and usually is discussed to some
length. There exist some solutions to this problem that use tracing [1] to
forcefully terminate a thread, but these of course only work if the source
of trouble is a sequence of statements, not a single blocking one.

I myself had a similar problem a few days ago, and started using fork() and
killing the subprocesses. Right after I implemented my little framework, I
found that QThread from qt had a terminate method. Fearing my work had been
uneccessary, I tried to use them - and found that not only my thread, but
the whole program died when terminating the thread. That was because of
omniorb beeing in an inconsistent state.

Maybe you don't experience this using your code, but it certainly proved
that the arguments for deprecating thread terminating methods in java and
obmitting them in python seem to be valid.

[
[1]http://groups-beta.google.com/group..._doneTitle=Back+to+Search&&d#2af9df4b63a48cbc
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,780
Messages
2,569,611
Members
45,285
Latest member
CryptoTaxxSoftware

Latest Threads

Top