#1948 socket-2.4 fails on WinNT

obsolete: 8.4b1

In the current HEAD, socket-2.4 appears not to be
working owing to some sort of synchronization problem
within the test case.

==== socket-2.4 tcp connection with server interface specified FAILED
==== Contents of test case:

removeFile script
set f [open $path(script) w]
puts $f {
set timer [after 2000 "set x done"]
set f [socket -server accept -myaddr [info hostname] 0]
proc accept {file addr port} {
global x
puts "[gets $file]"
close $file
set x done
puts ready
puts [lindex [fconfigure $f -sockname] 2]
vwait x
after cancel $timer
close $f
close $f
set f [open "|[list $::tcltest::tcltest $path(script)]" r]
gets $f x
gets $f listen
if {[catch {socket [info hostname] $listen} sock]} {
set x $sock
} else {
puts $sock hello
flush $sock
lappend x [gets $f]
close $sock
close $f
set x

---- Result was:
couldn't open socket: connection refused
---- Result should have been (exact matching):
ready hello
==== socket-2.4 FAILED


  • Logged In: YES

    Sorry, I am unable to reproduce this on my Win2K system.
    Does this happen for every run, or only now and then ? How
    many server sockets are open on your system ? Maybe you
    exceeded what the system allows.

    The only possible sync problem which might exist is the race
    between reading the port number from the pipe and opening
    the socket in the caller, and writing the port number and
    entering the event loop in the server. I am unsure about this
    because the server socket already does exist at that time
    and maybe the OS buffers a connection request coming in,
    before the event loop starts looking for such events.

    And this we should be able to avoid with a small delay
    between 'gets $f listen' and the 'socket' command. [after
    1000] or so.

    Can you test this ?

  • Kevin B KENNY
    Kevin B KENNY

    Logged In: YES

    Sorry about the false alarm. There was a brief DNS outage while I was running the test suite, and that apparently
    caused the problem.

    We might want to have the tests use in place of [info hostname] when making connections that are
    known to be on the local host.

  • Kevin B KENNY
    Kevin B KENNY

    • status: open --> closed-invalid
  • Jeffrey Hobbs
    Jeffrey Hobbs

    Logged In: YES

    It is important to note that [info hostname] will of course
    follow different code paths, so it may not be appropriate to
    replace it for all tests. Also, at the OS leve, the loopback
    address often follows a different codepath than referring to
    machine by name or global IP. This may not be important to
    all tests, but there are likely a few where info hostname
    should still be used.

  • Logged In: YES

    From the comments below and talking with Jeff I have
    decided to make the change for the test mentioned in this
    report, i.e. socket-2.4, but nowhere else.