embedding: forcing an interpreter to end

[pdectm@yahoo.com]

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_C lear(xxx);
PyThreadState_D elete(xxx); // Fatal Python error: no last thread
Py_EndInterpret er(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_AcquireL ock();
gtstate = Py_NewInterpret er();

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

printf( "Interprete r was shutdown ... yeah \n" );

PyEval_ReleaseL ock();
}

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

Py_Initialize() ;
PyEval_InitThre ads();
tstate = PyEval_SaveThre ad();

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

sleep(3);

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

PyThreadState_C lear(gtstate);
//PyThreadState_D elete(gtstate); // Fatal Python error:
Py_EndInterpret er: not the last thread

PyThreadState_S wap(gtstate);
Py_EndInterpret er(gtstate);

PyEval_ReleaseL ock();
sleep(3); // Segmentation fault
PyEval_AcquireT hread(tstate);
Py_Finalize();

return(0);
}

[Diez B. Roggisch]

Re: embedding: forcing an interpreter to end

Hi,
[color=blue]
> I've googled my heart out and reread the threading API countless times.
> Any suggest or hints would be greatly appreciated.[/color]

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/comp.lang.pytho n/browse_thread/thread/ace7c98ef31bbf2 d/2af9df4b63a48cb c?q=python+kill able+thread&_do ne=%2Fgroups%3F q%3Dpython+kill able+thread%26h l%3Den%26lr%3D% 26ie%3DUTF-8%26c2coff%3D1% 26sa%3DN%26tab% 3Dwg%26&_doneTi tle=Back+to+Sea rch&&d#2af9df4b 63a48cbc
--
Regards,

Diez B. Roggisch