socket closes prematurely

[bjarthur]

1a. first, listen, accept, readline, and println on the server-session:

julia> server = listen(2000)
Base.TCPServer(active)

julia> while true
            sock = accept(server)
            @async begin
                  while isopen(sock) || nb_available(sock)>0
                       tmp = chomp(readline(sock))
                       length(tmp)==0 && continue
                       println(tmp)
                  end
            end
      end
Task (runnable) @0x00007fdab1abcc40

2b. then, connect and println on client #1:

julia> sock = connect(2000)
TCPSocket(open, 0 bytes waiting)

julia> println(sock,"1")

3c. similarly, on client #2:

julia> sock = connect(2000)
TCPSocket(open, 0 bytes waiting)

julia> println(sock,"2")

4d. then println again back on client #1:

julia> println(sock,"1")

5e. ditto on client #2:

julia> println(sock,"2")

6f. now close client #2:

julia> close(sock)

7g. then back to client #1, and println no longer works:

julia> println(sock,"1")

note that if steps 4d and 5e are skipped, 7g works. also, client #2 still works if #1 is closed.

this in on 0.5.0-rc3 and scientific linux 7.

[bjarthur]

https://groups.google.com/forum/#!topic/julia-users/uy18lP-a440

[JeffBezanson]

This is because every time around the while loop the same sock variable is overwritten, changing the value of sock in all of the tasks. You can create a new variable for each iteration by writing let sock = accept(server) ... end instead.

[bjarthur]

oi, thanks, sorry for the hash.

however, does @async no longer "wrap the expression in a let x=x, y=y, ... block to create a new scope with copies of all variables referenced in the expression" ? the above example works in 0.4, so something has changed.

[JeffBezanson]

Hmm, good point. That does appear to be unintentional, but I actually think it's a good idea to remove the implicit let those docs are talking about --- less magical.

[tkelman]

reopen to fix the docs?

[bjarthur]

would need to add it to NEWS.md, the docstring, and the example in Networking and Streams

[bjarthur]

is there a consensus to leave intact this unintentional change? is so, i can work on a PR to document it.

[tkelman]

I actually think it's a good idea to remove the implicit let

Sounds like Jeff thinks so?

[bjarthur]

@fetchfrom also uses a magical closure. should we get rid of that too?

[ViralBShah]

cc @amitmurthy

[bjarthur]

@amitmurthy can you please comment on this change to the @async API? would be nice to have it addressed before the 0.6 feature freeze at the end of the year. thanks.

[amitmurthy]

Same as #19468

I am fine with removing the implicit let. However, it is not just a doc change as currently a bug is preventing automatic localization of variables. The fix should

• remove localize_vars from all exported macros/functions using it.
• change docs
• add a NEWS item for the changed behavior marking it as a breaking change.

[bjarthur]

closed by #19594