Embedding and threads ?

[Bo Lorentsen]

On Thu, 2002-05-30 at 19:27, Martin v. Löwis wrote:

> Python has three namespaces: locals, globals, and builtins. The
> parameters allow you to specify the locals and globals, since that
> allows you to execute your expression in a reasonably "fresh"
> environment, and since Python could not obtain these dictionaries
> otherwise (notice that there is a "global" namespace per module).
But I have to set the builtins explictly, and that sounds to me like
they where not there in there first place. But then I set the
__builtins__ namespace, do I then set it for all elements (interpreter
states) in the Python module ?

> That is not the case. There is one thread state per thread. All but
> one thread is blocked at any point in time (unless the other threads
> execute unrelated C code); those threads have their thread state
> preserved in a local variable at the point where they last executed
> BEGIN_ALLOW_THREADS.
So thread states can't run one in each fysical thread ! I think this is
a bit confusing, as I don't see how to use Python in parallel from a
threaded C/C++ application, or even how threads would work internally in
Python itself, except if this is a light weight thread system.

> > but is it not possible to "swap" these after getting the GIL, or am
> > I totally off track here ?
> 
> It certainly is possible.
But I will not be able to have two Python interpreter states running in
true parallel ?

> There is no difference between "inside Python", and "from C". Write
> down what you would do in Python, then translate that literally into C
> (using PyObject_CallFunction etc). You may find it useful to make a
> Python wrapper around rexec which customizes it to your need, and call
> that wrapper from the C code.
Ok, I could just look more into the "rexec" code, to see what is going
on.

> That won't help - one can modify sys.path to overcome that limitation.
> The best way to not allow execution of dangerous code is not to
> include such code in your binary in the first place.
Good point, I drop that :-)

> Not having to edit the Python source is a desirable thing to
> do. Having a custom build of Python is IMO reasonable in about any
> embedding application.
I think I will try to handle Python mostly like a blackbox. If one start
to reconfigure the code, one will be more locked in regarding Python
versions and such.

> Good luck!
Thanks, I need that :-)

/BL