Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #99400 > unrolled thread
| Started by | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| First post | 2015-11-24 14:53 -0700 |
| Last post | 2015-11-24 14:53 -0700 |
| Articles | 1 — 1 participant |
Back to article view | Back to comp.lang.python
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Bi-directional sub-process communication Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-24 14:53 -0700
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2015-11-24 14:53 -0700 |
| Subject | Re: Bi-directional sub-process communication |
| Message-ID | <mailman.38.1448402040.20593.python-list@python.org> |
On Mon, Nov 23, 2015 at 10:25 PM, Cameron Simpson <cs@zip.com.au> wrote: > Then #3. I would have a common function/method for submitting a request to > go to the subprocess, and have that method return an Event on which to wait. > Then caller then just waits for the Event and collects the data. Obviously, > the method does not just return the Event, but an Event and something to > receive the return data. I've got a class called a Result for this kind of > thing; make a small class containing an Event and which will have a .result > attribute for the return information; the submitting method allocates one of > these and returns it. The response handler gets the instance (by looking it > up from the tag), sets the .result attribute and fires the Event. Your > caller wakes up from waiting on the Event and consults the .result > attribute. Your Result sounds suspiciously like a Future. ;-)
Back to top | Article view | comp.lang.python
csiph-web