Path: csiph.com!news.mixmin.net!weretis.net!feeder4.news.weretis.net!ecngs!testfeeder.ecngs.de!81.171.118.63.MISMATCH!peer03.fr7!news.highwinds-media.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Ian Kelly <ian.g.kelly@gmail.com>
Newsgroups: comp.lang.python
Subject: Re: Bi-directional sub-process communication
Date: Mon, 23 Nov 2015 12:55:49 -0700
Lines: 61
Message-ID: <mailman.74.1448308612.2291.python-list@python.org>
References: <B819AD72-C0F9-4E6C-992A-5E5556979883@ravnalaska.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <B819AD72-C0F9-4E6C-992A-5E5556979883@ravnalaska.net>
Precedence: list
Xref: csiph.com comp.lang.python:99280

On Mon, Nov 23, 2015 at 10:54 AM, Israel Brewster <israel@ravnalaska.net> w=
rote:
> Concern: Since the master process is multi-threaded, it seems likely enou=
gh that multiple threads on the master side would make requests at the same=
 time. I understand that the Queue class has locks that make this fine (one=
 thread will complete posting the message before the next is allowed to sta=
rt), and since the child process only has a single thread processing messag=
es from the queue, it should process them in order and post the responses (=
if any) to the master_queue in order. But now I have multiple master proces=
ses all trying to read master_queue at the same time. Again, the locks will=
 take care of this and prevent any overlapping reads, but am I guaranteed t=
hat the threads will obtain the lock and therefore read the responses in th=
e right order? Or is there a possibility that, say, thread three will get t=
he response that should have been for thread one? Is this something I need =
to take into consideration, and if so, how?

Yes, if multiple master threads are waiting on the queue, it's
possible that a master thread could get a response that was not
intended for it. As far as I know there's no guarantee that the
waiting threads will be woken up in the order that they called get(),
but even if there are, consider this case:

Thread A enqueues a request.
Thread B preempts A and enqueues a request.
Thread B calls get on the response queue.
Thread A calls get on the response queue.
The response from A's request arrives and is given to B.

Instead of having the master threads pull objects off the response
queue directly, you might create another thread whose sole purpose is
to handle the response queue. That could look like this:


request_condition =3D threading.Condition()
response_global =3D None

def master_thread():
    global response_global
    with request_condition:
        request_queue.put(request)
        request_condition.wait()
        # Note: the Condition should remain acquired until
response_global is reset.
        response =3D response_global
        response_global =3D None
    if wrong_response(response):
        raise RuntimeError("got a response for the wrong request")
    handle_response(response)

def response_thread():
    global response_global
    while True:
        response =3D response_queue.get()
        with request_condition:
            response_global =3D response
            request_condition.notify()


As another option you could use a multiprocessing.Manager to
coordinate passing the response back more directly, but starting a
third process seems like overkill for this.