Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #105409
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Newsgroups | comp.lang.python |
| Subject | Re: multiprocessing, pool, queue length |
| Date | 2016-03-21 15:24 -0600 |
| Message-ID | <mailman.465.1458595524.12893.python-list@python.org> (permalink) |
| References | <0qu4scx89u.ln2@news.c0t0d0s0.de> <mailman.456.1458587577.12893.python-list@python.org> <olv5scxgnt.ln2@news.c0t0d0s0.de> |
On Mon, Mar 21, 2016 at 1:46 PM, Michael Welle <mwe012008@gmx.net> wrote: > Wait on the result means to set a multiprocessing.Event if one of the > consumers finds the sentinel task and wait for it on the producer? Hmm, > that might be better than incrementing a counter. But still, it couples > the consumers and the producer more than I like. No, I mean calling AsyncResult.wait() on the result of the sentinel task (or just calling Pool.apply instead of Pool.apply_async in the first place). > Another idea that I had is to use map() instead of map_async() and then > put the producer in its own process. That should work if job creation is > fast. Essentially the same thing.
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
multiprocessing, pool, queue length Michael Welle <mwe012008@gmx.net> - 2016-03-21 11:25 +0100
Re: multiprocessing, pool, queue length Ian Kelly <ian.g.kelly@gmail.com> - 2016-03-21 13:12 -0600
Re: multiprocessing, pool, queue length Michael Welle <mwe012008@gmx.net> - 2016-03-21 20:46 +0100
Re: multiprocessing, pool, queue length Ian Kelly <ian.g.kelly@gmail.com> - 2016-03-21 15:24 -0600
Re: multiprocessing, pool, queue length Michael Welle <mwe012008@gmx.net> - 2016-03-22 07:19 +0100
csiph-web