xmlrpc idea for getting around the GIL
sturlamolden
sturlamolden at yahoo.no
Wed Dec 2 09:42:58 EST 2009
On 2 Des, 02:47, Patrick Stinson <patrickstinson.li... at gmail.com>
wrote:
> We don't need extension modules, and all we need to do is run some
> fairly basic scripts that make callbacks and use some sip-wrapped
> types.
Sure, you use SIP but not extension modules...
> - Python is not suitable for real-time work.
>
> Not true. We have been running python callback code using
> PyObject_CallObject from within our audio thread for some time without
> a problem, and it's *extremely* fast.
It seems you are confusing "real-time" with "real-fast". The fact that
something runs fast does not make it "real-time".
Python is not suitable for real-time applications, nor are the OSes
commonly used to run Python.
> We
> need just a liiiitle push to get our code to work at low latencies,
> and the only thing that is standing in our way is that all threads
> 9usually around 20 have to block on the Gil, and this causes small
> gaps in the sound at low latencies (around 5ms, or 64 sample period).
>
> ...almost perfect.
Python is not programmed with real-time applications in mind: You have
no guarrantees on maximum time-lag when a thread is blocked on the
GIL.
"Priority requests" (i.e. pre-emptive multitasking) was removed from
Antoine's "newgil" branch, but that is the kind of mechanism you would
need. Even with priority requests, Python would not be suitable for
real-time apps, as extension modules (e.g. C++ wrapped with SIP) can
hold the GIL forever.
You will also need an OS with a real-time scheduler and a real-time C
library, such as QNX or VxWorks.
I find thea idea of a true real-time Python very interesting, but it
would take a completely reworked interpreter.
More information about the Python-list
mailing list