xmlrpc idea for getting around the GIL

["Martin v. Löwis"]

> What I meant was that I am *not allowed* to make calls to the CPython
> API from the threads I currently have because these threads are high
> priority and are never allowed to make blocking calls. Fortunately,
> each of these threads can have a completely separate interpreter, so
> my idea was to create a daemon process for each thread. This daemon
> would contain the libpython symbols and would make the CPython calls.
> This would keep my current threads from having to contend over the
> single GIL.

If this ("never allowed to make blocking calls") is a strict
requirement, then this is no solution, either. Communicating to the
remote process would involve IO, and all IO operations may block.
Of course, you might use non-blocking IO, in which case I wonder how
the thread continues if it finds that the IO is blocking. I also wonder
how the thread will find out that the result of the computation is
available, when it is not allowed to wait for the result.

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.

> Damn you, Gil.

It may sound to you like the GIL is responsible for that. However,
consider a world where the GIL was removed in Python. There would
*still* be synchronization for data structures be going on. As you
are not allowed to have any blocking operation in the high-priority
threads, you *still* couldn't directly call the Python interpreter
(or any other thread-safe library) from your high-priority threads.

Regards,
Martin