[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 g

[issue6147] multithreading.Pool.map() crashes Windows computer

Jesse Noller added the comment: Can you wrap the execution of the main code in a if __name__ == "__main__": block, as shown in the documentation? Failure to do so can cause a fork bomb on windows -- ___ Python tracker <http://bu

[issue6147] multithreading.Pool.map() crashes Windows computer

Jesse Noller added the comment: Hey Alex; This isn't a bug, or a feature request. On win32, the way multiprocessing fakes a fork() is by creating a special subprocess which essentially imports and executes the function/process to be run, communication is handled through pickling and

[issue6142] Distutils doesn't remove .pyc files

Changes by Jesse Noller : -- assignee: -> tarek components: +Library (Lib) nosy: +tarek priority: -> normal ___ Python tracker <http://bugs.python.org/

[issue6273] Add client side certificate support to httplib

New submission from Jesse Noller : The attached patch adds client-side cert support to httplib, as well as validation. Rather than just commit this, I would like to have additional review. Also, ideally this could be added to 2.6 maint (it seems like a pretty big hole) as well as 2.7/3.0

[issue6273] Add client side certificate support to httplib

Jesse Noller added the comment: And yes, I need to finish the doc patch. -- ___ Python tracker <http://bugs.python.org/issue6273> ___ ___ Python-bugs-list mailin

[issue6273] Add client side certificate support to httplib

Jesse Noller added the comment: On Jun 12, 2009, at 5:00 PM, Martin v. Löwis wrote: > > Martin v. Löwis added the comment: > >> The attached patch adds client-side cert support to httplib, as >> well as >> validation. Rather than just commit this, I would l

[issue6273] Add client side certificate support to httplib

Jesse Noller added the comment: I'm going to close this until I come up with a more complete patch, and target it for 2.7. No reason to keep this in the tracker as-is -- resolution: -> invalid status: open -> closed ___ Python tra

[issue5313] multiprocessing.process using os.close(sys.stdin.fileno) instead of sys.stdin.close()

Jesse Noller added the comment: Attached is a patch which calls close() first, and then attempts to close the fd. In the case of an attribute errors (fileno doesn't exist) we simply set it to devnull. This is just a thought, feedback welcome - right now this allows this fixes issue

[issue5313] multiprocessing.process using os.close(sys.stdin.fileno) instead of sys.stdin.close()

Jesse Noller added the comment: On Fri, Jun 19, 2009 at 11:55 AM, OG7 wrote: > > OG7 added the comment: > > One shouldn't close the fileno after the file has been closed. The > stdlib raises an error, and the open(os.devnull) won't be reached. If no > error was thr

[issue6337] multiprocessing module: Double close of sys.stdin - ID: 2811568

Jesse Noller added the comment: Dupe of issue 5313 -- resolution: -> duplicate status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue6362] multiprocessing: handling of errno after signals in sem_acquire()

Jesse Noller added the comment: Thank you Ryan -- assignee: -> jnoller priority: -> normal ___ Python tracker <http://bugs.python.org/issue6362> ___ ___

[issue4660] multiprocessing.JoinableQueue task_done() issue

Jesse Noller added the comment: I'm leaning towards the properly protecting JoinableQueue.put() fix, I'm not a terribly big fan of removing error checking. I'm trying to carve off time this week to beat on my bug queue, so I'm hoping to be able to commit something (on

[issue6064] Add "daemon" argument to threading.Thread constructor

Jesse Noller added the comment: +1 to this, and I'd need to make the same patch/change to multiprocessing.Process as well -- nosy: +jnoller ___ Python tracker <http://bugs.python.org/i

[issue6269] threading documentation makes no mention of the GIL

Jesse Noller added the comment: I strongly disagree with the wording of the patch as-is. It makes no mention of the simple fact that I/O blocked threads get a benefit with threading, and so on. I do agree with adding some details about this in the core documentation however

[issue5879] multiprocessing - example "pool of http servers " fails on windows "socket has no attribute fromfd"

Changes by Jesse Noller : -- assignee: -> jnoller ___ Python tracker <http://bugs.python.org/issue5879> ___ ___ Python-bugs-list mailing list Unsubscri

[issue5906] Risk of confusion in multiprocessing module - daemonic processes

Jesse Noller added the comment: committed, r73693 on trunk -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue5740] multiprocessing.connection.Client API documentation incorrect

Jesse Noller added the comment: Committed, r73694 on trunk - will merge to 3k -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue5313] multiprocessing.process using os.close(sys.stdin.fileno) instead of sys.stdin.close()

Jesse Noller added the comment: Attached is a patch with docs, tests and the fix as suggested by OG7 (whom I can't add to the ACKS without a real name). Please check the additional doc note I added to the all platforms programming guidelines. -- Added file: http://bugs.pytho

[issue5331] multiprocessing hangs when Pool used within Process

Jesse Noller added the comment: Patch attached to issue 5313, please review -- ___ Python tracker <http://bugs.python.org/issue5331> ___ ___ Python-bugs-list m

[issue5155] Multiprocessing.Queue created by sub-process fails when used in sub-sub-process ("bad file descriptor" in q.get())

Jesse Noller added the comment: Patch attached to issue 5313, please review. -- ___ Python tracker <http://bugs.python.org/issue5155> ___ ___ Python-bugs-list m

[issue5503] multiprocessing/connection.py wrong pipe name under win32

Jesse Noller added the comment: Closing; without the exception/more details, and with multiprocessing working on WIN32 I don't have anything to go on. -- resolution: -> wont fix status: pending -> closed ___ Python tracker <http://b

[issue5313] multiprocessing.process using os.close(sys.stdin.fileno) instead of sys.stdin.close()

Changes by Jesse Noller : Removed file: http://bugs.python.org/file14319/stdin-patchv1.patch ___ Python tracker <http://bugs.python.org/issue5313> ___ ___ Python-bug

[issue5313] multiprocessing.process using os.close(sys.stdin.fileno) instead of sys.stdin.close()

Changes by Jesse Noller : Removed file: http://bugs.python.org/file14320/0001-Fix-issue-5313.patch ___ Python tracker <http://bugs.python.org/issue5313> ___ ___ Python-bug

[issue5313] multiprocessing.process using os.close(sys.stdin.fileno) instead of sys.stdin.close()

Jesse Noller added the comment: Committed in r73708 on trunk -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue5155] Multiprocessing.Queue created by sub-process fails when used in sub-sub-process ("bad file descriptor" in q.get())

Jesse Noller added the comment: Committed in r73708 on trunk -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue5331] multiprocessing hangs when Pool used within Process

Jesse Noller added the comment: Committed in r73708 on trunk -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue6407] multiprocessing Pool should allow custom task queue

Jesse Noller added the comment: I'm not against this; new features will only be committed to the 2.7 and 3.1.x branches however. Something to help speed this up would be an actual patch with docs/tests for the module made against python trunk. That way I could review and simply s

[issue6407] multiprocessing Pool should allow custom task queue

Jesse Noller added the comment: Thanks Matthew - I agree, it's simple. But fixing the code is 1/3 of the patch. I'll need to add tests/update the ones there as well as modify the .rst documentation. -- ___ Python tracker <http://bu

[issue8713] multiprocessing needs option to eschew fork() under Linux

Jesse Noller added the comment: This is on my wish list; but I have not had time to do it. Patch welcome. -- ___ Python tracker <http://bugs.python.org/issue8

[issue8713] multiprocessing needs option to eschew fork() under Linux

Jesse Noller added the comment: I pretty much agree with (b) an argument - your gut instinct is correct - there's a long standing thread in python-dev which pretty much solidified my thinking about whether or not we need this (we do). Any patch has to be backwards compatible by the wa

[issue8995] Performance issue with multiprocessing queue (3.1 VS 2.6)

Jesse Noller added the comment: No - I don't know of anything which would trigger this in 3.1 off the top of my head. The performance degradation is pretty worrisome -- ___ Python tracker <http://bugs.python.org/i

[issue9144] Import error for multiprocessing in 2.7rc2 on Windows

Jesse Noller added the comment: the patch looks good to me - unless someone beats me to it, I'm going to commit it shortly to fix 2.7 -- ___ Python tracker <http://bugs.python.org/i

[issue9144] Import error for multiprocessing in 2.7rc2 on Windows

Jesse Noller added the comment: Pushed it in r82489 - worked for me on Linux and OS/X. Please let me know if anything else comes up. -- status: open -> closed ___ Python tracker <http://bugs.python.org/iss

[issue4106] multiprocessing occasionally spits out exception during shutdown

Jesse Noller added the comment: Greg - what platform? -- ___ Python tracker <http://bugs.python.org/issue4106> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue4106] multiprocessing occasionally spits out exception during shutdown

Jesse Noller added the comment: Greg - this is actually a different exception then the original bug report; could you please file a new issue with the information you've provided? I'm going to need to find a 64bit ubuntu box as I don't hav

[issue9207] multiprocessing occasionally spits out exception during shutdown

Jesse Noller added the comment: Thanks greg; so this affects 2.6 as well (not using the backport at all) -- assignee: -> jnoller nosy: +jnoller ___ Python tracker <http://bugs.python.org/iss

[issue9207] multiprocessing occasionally spits out exception during shutdown (_handle_workers)

Changes by Jesse Noller : -- title: multiprocessing occasionally spits out exception during shutdown -> multiprocessing occasionally spits out exception during shutdown (_handle_workers) ___ Python tracker <http://bugs.python.org/iss

[issue9207] multiprocessing occasionally spits out exception during shutdown (_handle_workers)

Jesse Noller added the comment: Oh, you mean the backport from google code? The person who stepped up to maintain that has not refreshed that in some time. I need to decide what to do with it long term. I'm pretty sure it's badly ou

[issue9207] multiprocessing occasionally spits out exception during shutdown (_handle_workers)

Jesse Noller added the comment: Wait - so, you are pulling svn trunk, compiling and running your test with the built python executable? I'm not following the "multiprocessing-from-trunk" distinction unless you're picking the module out of the tree / compiling it and then

[issue9207] multiprocessing occasionally spits out exception during shutdown (_handle_workers)

Jesse Noller added the comment: Alright, I'm fighting ubuntu 64 bit in my vmware install right now, I'll see if I can get it up and running. -- ___ Python tracker <http://bugs.python.

[issue9162] License for multiprocessing files

Jesse Noller added the comment: Yes; the copyright has to stay; but the license data can leave afaik. -- ___ Python tracker <http://bugs.python.org/issue9

[issue9207] multiprocessing occasionally spits out exception during shutdown (_handle_workers)

Jesse Noller added the comment: I can confirm with a clean ubuntu 64 install, with a clean checkout of release27 that it explodes with that exception, while the stock 2.6.5 does not. -- ___ Python tracker <http://bugs.python.org/issue9

[issue9207] multiprocessing occasionally spits out exception during shutdown (_handle_workers)

Jesse Noller added the comment: It does not seem to appear on OS/X 10.6.4 - so the only question is does this show up on Ubuntu 32bit -- ___ Python tracker <http://bugs.python.org/issue9

[issue9207] multiprocessing occasionally spits out exception during shutdown (_handle_workers)

Jesse Noller added the comment: Correction; it can and does happen on OS/X. So, this is not a platform specific bug. -- ___ Python tracker <http://bugs.python.org/issue9

[issue9207] multiprocessing occasionally spits out exception during shutdown (_handle_workers)

Jesse Noller added the comment: Greg, can you comment out line 272 in Lib/multiprocessing/pool.py and tell me if you can reproduce? -- ___ Python tracker <http://bugs.python.org/issue9

[issue9207] multiprocessing occasionally spits out exception during shutdown (_handle_workers)

Jesse Noller added the comment: I'm not sure if there would still be the possibility; the thing which worries me is the debug() function vanishing on us - something not good is happening on interpreter shutdown. -- ___ Python tracker

[issue9162] License for multiprocessing files

Jesse Noller added the comment: Hi Stefan - I'm familiar with the license/etc of the original module. This bug isn't urgent; I shot a quick email to the PSF's secretary Pat to confirm we have a contributor agreement however. -- ___

[issue9162] License for multiprocessing files

Jesse Noller added the comment: Egad No! I gotcha. I'll find out what the deal with the contrib. agreement is. Pretty sure we had to wait on it when we brought it in. -- ___ Python tracker <http://bugs.python.org/i

[issue9207] multiprocessing occasionally spits out exception during shutdown (_handle_workers)

Jesse Noller added the comment: Greg - yeah. it's the same problem. -- ___ Python tracker <http://bugs.python.org/issue9207> ___ ___ Python-bugs-list m

[issue9207] multiprocessing occasionally spits out exception during shutdown (_handle_workers)

Jesse Noller added the comment: Talking with Brett; the fix should be as simple as keeping a reference to the debug function which we have in the imports. During interpreter shutdown, the sys.modules is iterated and each module replaced with None. Since the _handle_workers thread persists

[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly

Jesse Noller added the comment: thanks greg; I'm going to take a look and think about this. I'd like to resolve bug 9207 first though -- ___ Python tracker <http://bugs.python.

[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly

Changes by Jesse Noller : -- assignee: -> jnoller ___ Python tracker <http://bugs.python.org/issue9205> ___ ___ Python-bugs-list mailing list Unsubscri

[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly

Jesse Noller added the comment: Ugh. I'm going to have to think about the cleanest way of handling this case of functions vanishing from us since this is going to be more widespread inside the code. Suggestions welcome. -- ___ Python tr

[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly

Jesse Noller added the comment: A+ for creativity; I wouldn't have thought of that ;) -- ___ Python tracker <http://bugs.python.org/issue9205> ___ ___ Pytho

[issue9207] multiprocessing occasionally spits out exception during shutdown (_handle_workers)

Jesse Noller added the comment: Thank you for doing that footwork Greg, it means a lot to me. I'm leaning towards the patch to swallow the errors - I just wanted to ponder it just a tiny bit longer before I pull the trigger. -- ___ Python tr

[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly

Jesse Noller added the comment: Greg - I asked Ask to take a look - his celery package is a huge consumer of multiprocessing, and so I tend to run things past him as well. That said - to both of you - the fundamental problem the shutdown patch is trying to scratch is located in issue 9207

[issue9244] multiprocessing.pool: Worker crashes if result can't be encoded

Changes by Jesse Noller : -- assignee: -> jnoller nosy: +gdb ___ Python tracker <http://bugs.python.org/issue9244> ___ ___ Python-bugs-list mailing list Un

[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly

Jesse Noller added the comment: Passing the references seems to be a losing game; for _handle_workers - we only need 1 function (debug) - for others (say _join_exited_workers), we need references to reversed/range/len. A possible alternative is to make those threads non-daemon threads; but

[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly

Jesse Noller added the comment: You two are bigger users of this then I currently am (the curse/blessing of switching jobs), which is why I've let you hash it out. Let me point out: my goal is to deal with errors in a way which does not cause a total crash, a lockup, or hanging proc

[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly

Jesse Noller added the comment: (sorry, I thought I had replied to your comment when I hadn't!) I think we can get away with a new optional kwarg. -- ___ Python tracker <http://bugs.python.org/i

[issue5001] Remove assertion-based checking in multiprocessing

Jesse Noller added the comment: @Mark Yeah - I'm the current multiprocessing maintainer. If I fix it, I'll just commit it :) I filed this as a to do against myself. -- ___ Python tracker <http://bugs.python.

[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

Jesse Noller added the comment: @ray - you probably don't have the "dcon" binary on your path. bug.py calls a subprocess call. -- ___ Python tracker <http://bugs.py

[issue6720] multiprocessing logging

Jesse Noller added the comment: The backport of multiprocessing is currently stale; and there are a few bugs in the tracker assigned to christian or myself in regards to it. If it's not too much trouble, I'd leave this one alone until the exact future of the backport can b

[issue9513] test_multiprocessing skipped on Windows

Jesse Noller added the comment: The relative imports have been more of a pain then they've helped. I'm fine with nuking them so long as the test suite passes. -- ___ Python tracker <http://bugs.python.

[issue8184] multiprocessing.managers will not fail if listening ocket already in use

Jesse Noller added the comment: Mark - did you observe the behavior in the Op? He's not stating the the code snippet runs fine, but that the second run at the same time on windows to cause a conflict. We need to show that either running it twice, at the same time against the same s

[issue8426] multiprocessing.Queue fails to get() very large objects

Jesse Noller added the comment: I don't know that it's unreasonable to send that much data, but it would certainly be slow, and I would not recommend it. Therefore, this is still on the list for when I have time -- ___ Python trac

<    1   2   3   4   5   6