[issue6056] socket.setdefaulttimeout affecting multiprocessing Manager

Changes by Richard Oudkerk : -- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed type: crash -> behavior ___ Python tracker ___ __

[issue6056] socket.setdefaulttimeout affecting multiprocessing Manager

Roundup Robot added the comment: New changeset 4e85e4743757 by Richard Oudkerk in branch '2.7': Issue #6056: Make multiprocessing use setblocking(True) on the sockets it uses. http://hg.python.org/cpython/rev/4e85e4743757 New changeset 290f04722be3 by Richard Oudkerk in branch '3.2': Issue #605

[issue6056] socket.setdefaulttimeout affecting multiprocessing Manager

Changes by Richard Oudkerk : -- nosy: +sbt ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.or

[issue6056] socket.setdefaulttimeout affecting multiprocessing Manager

Derek Wilson added the comment: Thanks, Jim, here is an updated patch. 1) I feel like it is clearly not-a-feature. Currently 2.7 crashes if remote managers are used and socket.setdefaulttimeout is anything other than None. Crashing seems bad and all this does is keep multiprocessing connecti

[issue6056] socket.setdefaulttimeout affecting multiprocessing Manager

Jim Jewett added the comment: The wording in 138415 suggested this patch was changing socket to not support timeouts -- which would be unacceptable. But the actual patch only seems to touch multiprocessing/connection.py -- a far more reasonable change. Unfortunately, the patch no longer ap

[issue6056] socket.setdefaulttimeout affecting multiprocessing Manager

Derek Wilson added the comment: Any chance this patch will be accepted (or at least reviewed) soon? -- type: behavior -> crash versions: +Python 3.3, Python 3.4 ___ Python tracker __

[issue6056] socket.setdefaulttimeout affecting multiprocessing Manager

Derek Wilson added the comment: I was wrong about exit behavior of a process that has put to a queue -- it seems to behave as expected. i had been playing with a proxy to a queue rather than a queue (to which, if you put, the process can exit right away because the actual put happens in the p

[issue6056] socket.setdefaulttimeout affecting multiprocessing Manager

Derek Wilson added the comment: While having multiprocessing use a timeout would be great, I didn't really have the time to fiddle with the c code. Instead of using the socket timeout, I'm modifying all the sockets created by the socket module to have no timeout (and thus to be blocking) whic

[issue6056] socket.setdefaulttimeout affecting multiprocessing Manager

Jesse Noller added the comment: I agree derek, I think that would be a fine addition, however we lack a patch and I don't have the current bandwidth to add it. -- ___ Python tracker ___

[issue6056] socket.setdefaulttimeout affecting multiprocessing Manager

Derek Wilson added the comment: This should be higher priority as one of the major benefits of the multiprocessing module is remote process management in a completely transparent manner. socket timeouts are very important in this context as blocking forever waiting for a connection is not alw

[issue6056] socket.setdefaulttimeout affecting multiprocessing Manager

Changes by Mark Lawrence : -- stage: -> needs patch versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6 ___ Python tracker ___ _

[issue6056] socket.setdefaulttimeout affecting multiprocessing Manager

Changes by Ask Solem : -- nosy: +asksol ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/m

[issue6056] socket.setdefaulttimeout affecting multiprocessing Manager

Jesse Noller added the comment: Well; I'm pretty tapped out right now - I think your idea of checking to see if a timeout has been set elsewhere makes sense. If you have the time to put together a patch (with a unit test or three :)) I can review it. Might take me a bit of time to get to this

[issue6056] socket.setdefaulttimeout affecting multiprocessing Manager

Ryan Leslie added the comment: Yeah, storing pickled queues in the file system makes for some easy IPC :) It wasn't a very original idea, I took the pickling comments in the documentation at face value: http://docs.python.org/library/multiprocessing.html#proxy-objects So, from what I can tell t

[issue6056] socket.setdefaulttimeout affecting multiprocessing Manager

Jesse Noller added the comment: Pickling the queue and then unpickling it in a new process is something I never thought of. That's interesting in and of itself ;) -- ___ Python tracker

[issue6056] socket.setdefaulttimeout affecting multiprocessing Manager

Changes by Benjamin Peterson : -- assignee: -> jnoller nosy: +jnoller ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubsc

[issue6056] socket.setdefaulttimeout affecting multiprocessing Manager

New submission from Ryan Leslie : Terminal 1: Python 2.6.1 (r261:67515, Apr 2 2009, 18:25:55) [GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from multiprocessing.managers import SyncManager >>> manager = SyncManager(au