Message100302
| Author | vilnis.termanis |
|---|---|
| Recipients | jnoller, meador.inge, vilnis.termanis |
| Date | 2010-03-02.16:38:45 |
| SpamBayes Score | 5.7821508e-06 |
| Marked as misclassified | No |
| Message-id | <1267547927.24.0.187973408387.issue8037@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
I couldn't see the wood for the trees: If put() is thread-blocking, multiprocessing.Queue is reduced to the same functionality as multiprocessing.queues.SimpleQueue, if I'm not mistaken. So maybe there should be a warning in the documentation that, for multiprocessing.[Joinable]Queue, modifying obj straight after calling put(obj) might en-queue the modified version. To me at least this wasn't obvious until I looked at the multiprocessing.queue code. I've modified the example for clarity and retracted the (unworthy) patch attempt. Regards, VT |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2010-03-02 16:38:47 | vilnis.termanis | set | recipients: + vilnis.termanis, jnoller, meador.inge |
| 2010-03-02 16:38:47 | vilnis.termanis | set | messageid: <1267547927.24.0.187973408387.issue8037@psf.upfronthosting.co.za> |
| 2010-03-02 16:38:46 | vilnis.termanis | link | issue8037 messages |
| 2010-03-02 16:38:45 | vilnis.termanis | create | |