This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Unsupported provider

Author dragonfyre13
Recipients asksol, dragonfyre13, dsvensson, gsson, jnoller, jodal
Date 2011-01-18.02:21:11
SpamBayes Score 8.686942e-09
Marked as misclassified No
Message-id <1295317273.5.0.825296403289.issue4892@psf.upfronthosting.co.za>
In-reply-to
Content
Wanted to quickly comment here, as I'm dealing with this issue as well, that I did find a workaround for avoiding it as far back as 2.6 (and it's not "don't pass a Pipe through a Pipe")

multiprocessing.reduction can already do this, though I don't entirely know why this isn't automatically done if it's a connection object.

>>> from multiprocessing import Pipe, reduction
>>> i, o = Pipe()
>>> reduced = reduction.reduce_connection(i)
>>> newi = reduced[0](*reduced[1])
>>> newi.send("hi")
>>> o.recv()
'hi'
>>> 

The reduced[0](*reduced[1]) line is actually calling reduction.rebuild_connection, as that function is the first element in the tuple, and the second element is the arguments to be passed to it. I can't seem to find any info on reduction.reduce_connection, so I don't know if this is how this was intended to be handled or not.

P.S. Tested on Win (XP) and Linux (Ubuntu 10.10), so there's no weird windows socket stuff that should go wrong with this.
History
Date User Action Args
2011-01-18 02:21:13dragonfyre13setrecipients: + dragonfyre13, jnoller, gsson, dsvensson, asksol, jodal
2011-01-18 02:21:13dragonfyre13setmessageid: <1295317273.5.0.825296403289.issue4892@psf.upfronthosting.co.za>
2011-01-18 02:21:11dragonfyre13linkissue4892 messages
2011-01-18 02:21:11dragonfyre13create