xmlrpc idea for getting around the GIL

[Patrick Stinson]

yes, using an rpc mechanism would insert a "blocking" call into a
thread in which I am "not allowed to make a blocking call," but actual
turn around times would be far better than forcing all threads to wait
on the Gil. As it stands, blocking on a single thread lock *almost*
works, and while we can claim this or that theoretical deficiency, the
proof is in the pudding and the pudding almost works. In fact, it does
work and has made us money, we just need one more once of performance
at low latencies and I can put this way.

Most machines that are running an audio sequencing host app are not
running other apps, and we can generally assume that the host app is
the only one using up the majority of resources on the local machine.
So, as it turns out, we can assume quite a predictable and stable
operating environment for our code.

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. Py_CallObject is our only entry point into python execution
from within the critical thread.

SIDE NOTE: There are a lot of use cases that the educated python
community is not familiar with that are really spectacularly
interesting, and I think some of the myths surrounding python are
incorrect.

- 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.

- Especially in a production environment.

Not true. We sell the industry leading sampler engine, and it has been
paying my salary for three years. It's high performance - every cycle
counts. Our sampled instruments is loaded as a plugin from third-party
applications and has been used to make movies you have seen. Our
customers love it and have never complained about problems with the
scripting engine.

Audio work is interesting, because you can think and think and think
about what will work and what wont, and at the end of the day all that
matters is that the audio is smooth and the code doesn't crash. 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.

On Sun, Nov 29, 2009 at 8:57 AM, Aahz <aahz at pythoncraft.com> wrote:
> In article <4b0b07a1$0$22159$9b622d9e at news.freenet.de>,
> =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=  <martin at v.loewis.de> wrote:
>>
>>In any case, I don't think you'll need a multi-process solution; a
>>single-process multi-threading approach will do fine. Just create
>>*another* thread, that runs at a low priority and is allowed to block.
>>Run the Python interpreter in that thread (create multiple of these if
>>you need them).  Then, use some queuing producer-consumer communication
>>between the high-priority thread and the low priority thread. Have the
>>high priority threads put requests into the queue, and the low priority
>>thread take them from the queue, dispatching them to Python. Make sure
>>you use non-blocking synchronization on the queue, or else priority
>>inheritance if you can get permission to do so.
>
> This is close to what I would recommend, but I would suggest that the
> low-priority thread make calls out to an external Python process; that
> way, you can have a Python worker pool of processes.  Based on what I've
> seen posted over the years, I generally recommend against instantiating
> multiple interpreter instances (although I've seen some success stories,
> I've seen more people butting their heads against the brick wall).
> --
> Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/
>
> The best way to get information on Usenet is not to ask a question, but
> to post the wrong information.
> --
> http://mail.python.org/mailman/listinfo/python-list
>