...
[Tim Peters[
How often do you see this? I haven't seen it yet, but I can't make
hours today to do this [by] hand.
[Sune B. Woeller]
The problem with a failing connect, and as consequence a hanging accept:
I have tested with your socktest111(), and experience the same thing with
that as
[Sune B. Woeller, on socktest29]
I have been running 8 simultaneous processes with socktest29() for
12 hours, on my xp box. No problems except for an occasional Address
already in use.
Which the code expects, and works around. Thank you, Sune! I ran the
same code, but with 3 processes, for
[...]
Key point: no socket is _listening_ on address (127.0.0.1, 1)
after this close(). From what comes later, I guess you believe that
no socket should be allowed to listen on that address again until all
connections made with that `a` also close, but I don't think you'll
find anything
The attached hasn't failed on my box (Win XP Pro SP2, Python 2.3.5)
for about two hours, running it in 3 processes. Was using 2 processes
before; discovered it was much easier to provoke problems using 3; but
the # of ephemeral ports in use increases too, typically hovering
between 7-8 thousand
Tim Peters wrote:
[Tim]
...
At this point, I wouldn't consider using it [SO_EXCLUSIVEADDRUSE]
unless someone first took the tedious time it needs to demonstrate that
when it is used, the thing that _I_ think is a bug here goes away in its
presence: the seeming ability of Windows to sometimes
Tim Peters wrote:
It's starting to look a lot like the Windows bind() implementation is
unreliable, sometimes (but rarely -- hard to provoke) allowing two
sockets to bind to the same (address, port) pair simultaneously,
instead of raising 'Address already in use' for one of them. Disaster
Tim Peters wrote:
[Sune B. Woeller]
I will try to recreate the problem on other
flavours of windows asap. I will get back to you
later.
Cool! If you can, posting a self-contained program that demonstrates
the problem is the best way to make progress.
I guess my reporting was a bit too
I have made two similar testprograms in c++, and the problem also occurs there.
Exactly the same pattern as my python client/server scripts in the mail I am
replying to.
But then I stumbled upon this flag in the WinSock documentation:
SO_EXCLUSIVEADDRUSE
See the description here:
btw, the code is slightly modified versions of the getting started with Winsock
example:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/getting_started_with_winsock.asp
Sune B. Woeller wrote:
I have made two similar testprograms in c++, and the problem also
[Sune B. Woeller]
...
This is what I'm experiencing as well.
I can narrow it down a bit: I *always* experience one out of two
erroneous behaviours, as described below.
I see only one of the behaviors below (the second -- no problems), and
don't agree it's in error.
I tried to make an even
[Sune B. Woeller]
...
But then I stumbled upon this flag in the WinSock documentation:
SO_EXCLUSIVEADDRUSE
See the description here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/using_so_exclusiveaddruse.asp
Right, I vaguely wink knew about that. Note that
[Tim]
...
At this point, I wouldn't consider using it [SO_EXCLUSIVEADDRUSE]
unless someone first took the tedious time it needs to demonstrate that
when it is used, the thing that _I_ think is a bug here goes away in its
presence: the seeming ability of Windows to sometimes permit more
than
I will try to recreate the problem on other
flavours of windows asap. I will get back to you
later.
I guess my reporting was a bit too quick, sorry:
I'm running python 2.3.5, (installed from windows binary).
Zope 2.7.7 (not necessary for the test scripts)
Windows XP Home SP2 (blush - my laptop
I will try to recreate the problem on other
flavours of windows asap. I will get back to you
later.
I guess my reporting was a bit too quick, sorry:
I'm running python 2.3.5, (installed from windows binary).
Zope 2.7.7 (not necessary for the test scripts)
Windows XP Home SP2 (blush - my laptop
[Sune B. Woeller]
I will try to recreate the problem on other
flavours of windows asap. I will get back to you
later.
Cool! If you can, posting a self-contained program that demonstrates
the problem is the best way to make progress.
I guess my reporting was a bit too quick, sorry:
Not at
Tim Peters wrote:
[Sune B. Woeller]
...
I can see (with the excellent (and free) 'Process
Explorer' from sysinternals) that the python
processes always opens port 1, and connects by
that port to themselves on another port (for
instance 2550).
[Dieter Maurer]
You can find the
16 matches
Mail list logo
