By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,898 Members | 1,325 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,898 IT Pros & Developers. It's quick & easy.

python, dlls, and multiple instances

P: n/a
Is it a correct to assume that you can use multiple instances of
python altogether if each is loaded from a separate dll? For instance,
if I write a couple of dll/so libs, and each has python statically
linked in, is it safe to assume that since dlls use their own address
space then each dll would have it's own GIL, and will therefore
coexist safely within the same app? This is correct across all
platforms, yes?

I ask because I will be writing an audio plugin that uses python both
for the gui and the audio thread. The audio thread must not be
blocked, and will also be set up as a restricted execution environment
to prevent the usual dangerous calls to open, socket, etc. The python
running in the application thread may be blocked and may do whatever
it wants.

I think my understanding is correct since our current dll
implementation statically links python, and I know that the host app
(Ableton Live) also uses python for it's scripting engine. This should
be fun, since I've wanted to write a recipe for using python in an
audio plugin GUIs for a while now.

Cheers!
Jun 27 '08 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Is it a correct to assume that you can use multiple instances of
python altogether if each is loaded from a separate dll? For instance,
if I write a couple of dll/so libs, and each has python statically
linked in, is it safe to assume that since dlls use their own address
space
DLLs don't use their own address space. All DLLs of a single operating
system process use the same address space.

Different DLLs do use different portions of that address space.
then each dll would have it's own GIL, and will therefore
coexist safely within the same app? This is correct across all
platforms, yes?
No; it rather depends on the way the operating system resolves symbols.
On some systems (e.g. many Unix systems), there is only a single global
symbol table for the entire process. So when a shared library is loaded,
and needs to resolve its symbols (even the ones that it also defines
itself), it may end up finding the GIL in a different copy of the Python
interpreter, so they all share the GIL (even though there would have
been space for multiple GILs).

Regards,
Martin
Jun 27 '08 #2

P: n/a
ahh, ok. Looks like my fundamental understanding of how dlls work was
a little messed up. Thanks!

On Sun, Jun 1, 2008 at 10:42 AM, "Martin v. Lwis" <ma****@v.loewis.dewrote:
>Is it a correct to assume that you can use multiple instances of
python altogether if each is loaded from a separate dll? For instance,
if I write a couple of dll/so libs, and each has python statically
linked in, is it safe to assume that since dlls use their own address
space

DLLs don't use their own address space. All DLLs of a single operating
system process use the same address space.

Different DLLs do use different portions of that address space.
>then each dll would have it's own GIL, and will therefore
coexist safely within the same app? This is correct across all
platforms, yes?

No; it rather depends on the way the operating system resolves symbols.
On some systems (e.g. many Unix systems), there is only a single global
symbol table for the entire process. So when a shared library is loaded,
and needs to resolve its symbols (even the ones that it also defines
itself), it may end up finding the GIL in a different copy of the Python
interpreter, so they all share the GIL (even though there would have
been space for multiple GILs).

Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
Jun 27 '08 #3

This discussion thread is closed

Replies have been disabled for this discussion.