On 2 Des, 02:47, Patrick Stinson <patrickstinson.li...@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. -- http://mail.python.org/mailman/listinfo/python-list