Embedding and threads ?

[Martin v. Löwis]

Bo Lorentsen <bl at netgroup.dk> writes:

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

No. The code object has a link to the builtins, and the sys module
(and thus sys.modules) is a singleton, as well. So if the code performs

import string
string.secret_channel = "data"

then this assignment will survive PyEval_EvalCode invocations. See
Include/pystate.h for part of the state that is passed implicitly into
PyEval_EvalCode.

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

Just assume that the interpreter is a singleton; having multiple
interpreters might not work.

> What do you mean by a "rexec sandbox" ?

http://www.python.org/doc/lib/module-rexec.html

> How do I "disable dynamic loading" ? 

You need to edit pyconfig.h to not set HAVE_DYNAMIC_LOADING, then recompile 

> Is it possible to have some kind of module import callback, where I
> can decide what to allow and what not to.

That is currently not supported.

: I like to permit the user to use math, re and others, but he must
> not be able to open files, sockets, databases etc.

If you disable dynamic loading, and provide an appropriate config.c,
then you get a limitation to math, re, and others for free. Preventing
code from doing open() is not so trivial; you need to provide a custom
__builtins__ module - you could do that by editing the Python
interpreter code, by deleting things from __builtins__ at run-time, or
by using rexec.

> Will it be possible to totally disable these ? 

Depends on what you mean by "disable". If you want that writing to
stdout has no effect: that is certainly possible. Just put in a
file-like object whose .write method is a no-op.

>  And where will "print" in this case send its default output ?

print will always use sys.stdout, so that will be a no-op as well (the
arguments to the print will still be evaluated).

> What is GIL ?

The Global Interpreter Lock.

> Another thing. While using the "Py_CompileString", it has the third
> parameter, that I can't find much information about.

This controls the start symbol of the parsing. It is eval_input,
file_input, or single_input, and relates to the non-terminals in
Grammar/Grammar with the same names. If that is not clear, you need to
understand the notion of a start symbol in a grammar first.

Regards,
Martin