Embedding and threads ?

[Bo Lorentsen]

On Wed, 2002-05-29 at 15:38, Martin v. Löwis wrote:

First, thanks four your swift answer !

> > Now is this possible ? 
> 
> Yes, but you need to make additional modifications.
Thanks, I have been reading some more in the meantime, and even in the
source code too.

> > Will each python code run separatly, in issolated environments ?
> 
> No. Even if you manage to separate the interpreters, you will still
> get a single copy of the global variables.
Hmm, how about this when you are using the PyEval_EvalCode ? One of its
parameters is a global dict. Is this not separated 100 % from others ?

> > Will it coredump ?
> 
> Most likely. You need to acquire the Global Interpreter Lock before
> executing each piece of code.
This I need to be able to swap the Python thread state, and its related
interpreter, in a thread safe way ? For me it look like we would like an
extended API taking the PyInterpreter as first parameter (this pointer
:-), as the code in PyEval_EvalCode more or less do this by fetching the
"globaly set" PyInterpreter (ThreadState).

> 
> > Can I control what the python code is allowed to import, and where
> > stdout/err/in is directed ?
> 
> Certainly. To restrict imports, I recommend to compile and execute
> code fragments inside an rexec sandbox. Alternatively, since you are
> embedding Python, you could also disable dynamic loading of modules,
> and provide a fixed modules table in your executable.
What do you mean by a "rexec sandbox" ?

How do I "disable dynamic loading" ? Is it possible to have some kind of
module import callback, where I can decide what to allow and what not
to. I like to permit the user to use math, re and others, but he must
not be able to open files, sockets, databases etc.

> To control stdout/err/in, you need to assign to
> sys.stdout/err/in. This won't catch direct references to stdout from C
> code, which should be rare - if you ever trigger one of those in the
> Python core, you should report that as a bug.
So, what I do is to fetch these three, and setup another file handler ?

Will it be possible to totally disable these ? And where will "print" in
this case send its default output ? 

> > Are there any other way of controlling the execution environment of
> > earch thread, like getting a kind of execution context thingy ?
> 
> This is what you need to do: each thread must maintain a Python thread
> state, and the thread must hold the GIL.
What is GIL ?

Another thing. While using the "Py_CompileString", it has the third
parameter, that I can't find much information about. It seems like a way
to control what to compile, but I don't quite understand what and why. I
use "Py_file_input", as this work for me, but I don't quite understand
why. Can you help me on that ?

/BL