Message70632
| Author |
jnoller |
| Recipients |
benjamin.peterson, donmez, jnoller, mark.dickinson |
| Date |
2008年08月02日.14:23:56 |
| SpamBayes Score |
7.5565e-07 |
| Marked as misclassified |
No |
| Message-id |
<C3DECAA0-2819-4226-AA28-A3E6BB1BCF35@gmail.com> |
| In-reply-to |
<1217684660.86.0.707387583889.issue3419@psf.upfronthosting.co.za> |
| Content |
On Aug 2, 2008, at 9:44 AM, Mark Dickinson <report@bugs.python.org>
wrote:
>
> Mark Dickinson <dickinsm@gmail.com> 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 longer seeing any hangs in test_multiprocessing.py (at least,
> not in
> the last 500 runs :-)). (Though I am still seeing the incref error
> occasionally.)
>
> If anyone's prepared to answer a stupid question: I'm curious why
> failed
> socket connections occur at all. Is connecting to a socket generally
> considered an unreliable operation, or is there some aspect of the
> multiprocessing module that makes it potentially unreliable?
>
I believe the conn refused error is another race, the child processes
are connecting to a manager which is shutting down/gone
Thanks again mark- when I get a chance today I'll review/test/apply
the patch |
|