embedding: forcing an interpreter to end

[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);
}

 

[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