Message145170
| Author |
neologix |
| Recipients |
ezio.melotti, jackdied, jcea, michael.foord, neologix, pitrou, terry.reedy, vstinner |
| Date |
2011年10月08日.14:30:00 |
| SpamBayes Score |
5.4982056e-06 |
| Marked as misclassified |
No |
| Message-id |
<1318084202.09.0.634988790067.issue11812@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
> Attached patch reads the name of the server socket instead of using
> HOST or 'localhost'.
> By the way, why do we use 'localhost' instead of '127.0.0.1' for
> support.HOST? '127.0.0.1' doesn't depend on the DNS configuration of
> the host (especially its "hosts" file, even Windows has such file).
This might be a good idea.
Apparently, Windows 7 doesn't use its hosts file (yes, it does have one) to resolve 'localhost', but its DNS resolver, see http://serverfault.com/questions/4689/windows-7-localhost-name-resolution-is-handled-within-dns-itself-why
Depending on the DNS setup, it could lead to a latency which might explain such failures.
> Seems a clear race condition.
The code looks correct: a threading.Event is set by the server once it called listen(), point at which incoming connections should be queued (SYN/ACK is sent before accept()).
So I'd bet either on resolution delay (on Unix /etc/nsswitch.conf), or an overloaded machine. |
|