xmlrpc idea for getting around the GIL

[sturlamolden]

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.