[issue3419] multiprocessing module is racy

Jesse Noller <[EMAIL PROTECTED]> added the comment: r66161 on py3k merges forward the fix for this ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3419] multiprocessing module is racy

Jesse Noller <[EMAIL PROTECTED]> added the comment: Looks like Mark's patch was submitted as part of r66115 by Ben accidentally (as part of reverting r66114). I can confirm this patch resolves the incref issue as-is. I've run test_multiprocessing in a loop for about an hour now with no failure

[issue3419] multiprocessing module is racy

Changes by Mark Dickinson <[EMAIL PROTECTED]>: -- keywords: +needs review ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-lis

[issue3419] multiprocessing module is racy

Changes by Barry A. Warsaw <[EMAIL PROTECTED]>: -- priority: deferred blocker -> release blocker ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3419] multiprocessing module is racy

Mark Dickinson <[EMAIL PROTECTED]> added the comment: [jnoller] > As for if this should block the release, it should be resolved before > final, but should not block the next beta. So the priority should be 'deferred blocker', no? [cartman] > With trunk when running test_multiprocessing in a

[issue3419] multiprocessing module is racy

Mark Dickinson <[EMAIL PROTECTED]> added the comment: Here's a patch that fixes the incref problem for me. This *definitely* needs review from someone more familiar with the multiprocessing module than I am; I'm not at all confident that it won't break something else. The original problem:

[issue3419] multiprocessing module is racy

Ismail Donmez <[EMAIL PROTECTED]> added the comment: With trunk when running test_multiprocessing in a tight loop I saw another problem: test_multiprocessing Process Process-61: Traceback (most recent call last): File "/Users/cartman/Sources/py3k/Lib/multiprocessing/process.py", line 229, in

[issue3419] multiprocessing module is racy

Changes by Jesse Noller <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11038/mp_nohang.patch ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue3419] multiprocessing module is racy

Jesse Noller <[EMAIL PROTECTED]> added the comment: Thanks Mark, I've checked in the connection refused fix in r65645 on trunk ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3419] multiprocessing module is racy

Mark Dickinson <[EMAIL PROTECTED]> added the comment: > So rather than use a static list, I switched the code to use the > errno module. Yup. That's definitely a better solution. Your patch fixed the problem for me. Thanks! ___ Python tracker <[EMAIL PROT

[issue3419] multiprocessing module is racy

Jesse Noller <[EMAIL PROTECTED]> added the comment: Hey Mark - I took a look at the mp_nohang patch you added - and you're right, the connection refused error numbers are different from platform to platform. So rather than use a static list, I switched the code to use the errno module. Can yo

[issue3419] multiprocessing module is racy

Jesse Noller <[EMAIL PROTECTED]> added the comment: On Aug 7, 2008, at 5:26 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote: > > Mark Dickinson <[EMAIL PROTECTED]> added the comment: > > Adding Richard Oudkerk to the nosy list in case he can shed any > light on > this. > > Should this be consid

[issue3419] multiprocessing module is racy

Mark Dickinson <[EMAIL PROTECTED]> added the comment: Adding Richard Oudkerk to the nosy list in case he can shed any light on this. Should this be considered a release-blocker? -- nosy: +roudkerk ___ Python tracker <[EMAIL PROTECTED]>

[issue3419] multiprocessing module is racy

Mark Dickinson <[EMAIL PROTECTED]> added the comment: Hmmm. That last message wasn't too coherent; I really shouldn't try to post at 2:30am. Summary: the refcounting logic in the Server class is flawed. In Server.create(), the initial refcount of a newly-created shared object is set to No

[issue3419] multiprocessing module is racy

Mark Dickinson <[EMAIL PROTECTED]> added the comment: Here's what's going on with the incref error: Look in the Server class, in managers.py: consider a shared object with id 'id'. When a reference to the shared object is created, its id is added to the id_to_refcount dictionary: {id: None}

[issue3419] multiprocessing module is racy

Mark Dickinson <[EMAIL PROTECTED]> added the comment: > I believe the conn refused error is another race, the child processes > are connecting to a manager which is shutting down/gone After some research, I think it actually has to do with the value of the 'backlog' parameter when creating a

[issue3419] multiprocessing module is racy

Jesse Noller <[EMAIL PROTECTED]> added the comment: On Aug 2, 2008, at 9:44 AM, Mark Dickinson <[EMAIL PROTECTED]> wrote: > > Mark Dickinson <[EMAIL PROTECTED]> added the comment: > >> Are you looking at the conn refused or the incref error? > > The connection refused error. > > The attached p

[issue3419] multiprocessing module is racy

Mark Dickinson <[EMAIL PROTECTED]> added the comment: > Are you looking at the conn refused or the incref error? The connection refused error. The attached patch fixes the problem, for me. On my machine, the connection refused error code was 61 rather than 10061. With this patch, I'm no lon

[issue3419] multiprocessing module is racy

Jesse Noller <[EMAIL PROTECTED]> added the comment: Are you looking at the conn refused or the incref error? ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue3419] multiprocessing module is racy

Mark Dickinson <[EMAIL PROTECTED]> added the comment: > Looks like something in semaphore.c needs fixing, but I've no idea what. I take that back. It's nothing to do with semaphore.c. I'll keep trying. ___ Python tracker <[EMAIL PROTECTED]>

[issue3419] multiprocessing module is racy

Mark Dickinson <[EMAIL PROTECTED]> added the comment: For the connection refused error, the following script fails for me (again, on OS X 10.5.4) with the message: errno: [Errno 61] Connection refused on most runs. (If xrange(10) is replaced by a smaller range like xrange(4) then the script

[issue3419] multiprocessing module is racy

Mark Dickinson <[EMAIL PROTECTED]> added the comment: I'm also seeing the incref error occasionally, on OS X 10.5.4: == ERROR: test_remote (__main__.WithManagerTestRemoteManager) -

[issue3419] multiprocessing module is racy

Jesse Noller <[EMAIL PROTECTED]> added the comment: Ben's incref error != the connection refused error. Here's some information from Scott Leerssen who is using the original .52 code: Hi Jesse, I am having some trouble with the processing module (0.52) and thought you might be of some help si

[issue3419] multiprocessing module is racy

Jesse Noller <[EMAIL PROTECTED]> added the comment: This also happens under trunk -- versions: +Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue3419] multiprocessing module is racy

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: When running test_multiprocessing in a loop, I see: test test_multiprocessing failed -- Traceback (most recent call last): File "/temp/python/trunk/Lib/test/test_multiprocessing.py", line 1157, in test_remote queue = manager2.get_que

[issue3419] multiprocessing module is racy

New submission from Ismail Donmez <[EMAIL PROTECTED]>: Tested on MacOSX 10.5.4, running test_multiprocessing in a tight loop : [~/Sources/py3k]> while true;do ./python ./Lib/test/regrtest.py test_multiprocessing;done test_multiprocessing 1 test OK. test_multiprocessing 1 test OK. test_multiproc