Patrick Stinson schrieb:
On Mon, Nov 23, 2009 at 1:01 AM, Carl Banks <pavlovevide...@gmail.com> wrote:
On Nov 22, 10:58 pm, Patrick Stinson <patrickstinson.li...@gmail.com>
wrote:
On Sun, Nov 22, 2009 at 3:15 PM, Diez B. Roggisch <de...@nospam.web.de> wrote:
icating) the multiprocessing module would be ideal.
The problem is that the OP has a embedded application running threads.
multiprocssing doesn't help there.
that's right. I cannot make CPython calls from my original C-based threads.

It's quite possible to do that.  A thread started from C can make
calls to Python if it first calls PyGILState_Ensure, although you'd
have to make sure that the Python interpreter has been previously
initialized.  See PEP 311 for details.

http://www.python.org/dev/peps/pep-0311/

I also suggest that if you want people to be more receptive to write
your replies after the quoted text.  That is the custom in this
newsgroup/mailing list.


Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list


thanks for the tip.

What I meant was that I am *not allowed* to make calls to the CPython
API from the threads I currently have because these threads are high
priority and are never allowed to make blocking calls. Fortunately,
each of these threads can have a completely separate interpreter, so
my idea was to create a daemon process for each thread. This daemon
would contain the libpython symbols and would make the CPython calls.
This would keep my current threads from having to contend over the
single GIL.

My question was whether or not anyone has done anything like this in
C/C++. This situation is slightly unique in that I am trying to
maintain separate interpreters within a single app (which is currently
kind of hacked out using a single interpreter, but it's ugly), but I
could see how this sort of thing would be useful for other C/C++ apps
that implement an embedded scripting engine.

AFAIK, instantiating several interpreters is possible. There seem to be problems with extension modules, but maybe you don't need them, or can work around that problem.


http://mail.python.org/pipermail/python-dev/2006-December/070370.html

Diez
--
http://mail.python.org/mailman/listinfo/python-list

Reply via email to