Puzzling RemoteRef behavior #13592
Closed
malmaud opened this Issue on Oct 13, 2015 · 4 comments
Projects
None yet
Labels
bug
parallel
Milestone
No milestone
Assignees
No one assigned
3 participants
@malmaud
@JeffBezanson
@amitmurthy
Notifications

You’re not receiving notifications from this thread.
@malmaud
malmaud commented on Oct 13, 2015

This is probably a bug.

Here is the expected behavior:

julia> r=RemoteRef(1)
RemoteRef{Channel{Any}}(1,1,7)

julia> put!(r,:first)
RemoteRef{Channel{Any}}(1,1,7)

julia> put!(r,:second)
^CERROR: InterruptException:

julia> take!(r)
:first

julia> take!(r) # Blocks

Here is strange behavior:

julia> addprocs(1)
1-element Array{Int64,1}:
 2

julia> r=RemoteRef(2)
RemoteRef{Channel{Any}}(2,1,2)

julia> put!(r,:first)
RemoteRef{Channel{Any}}(2,1,2)

julia> put!(r,:second)
^CERROR: InterruptException:

julia> take!(r)
:first

julia> take!(r) 
:second

@malmaud malmaud added bug parallel labels on Oct 13, 2015
@JeffBezanson
The Julia Language member
JeffBezanson commented on Oct 21, 2015

I don't think this is a bug. We don't generally try to guarantee exactly what has or hasn't happened at the point when ^C is pressed. The implementation of remote put! has 2 steps: ask the remote processor to put the value, then wait for the request to finish. Here the second step gets interrupted. AFAICT changing this would require more round-trips.
@malmaud
malmaud commented on Oct 21, 2015

Fair. Still a bit disconcerting that a channel created to hold one element somehow ends up holding two elements.
@malmaud
malmaud commented on Oct 21, 2015

Oh nevermind, I understand what you're saying now: put!(::RemoteValue,:second) is still queued on the worker even after put!(::RemoterRef,:second) is interrupted on the client, so the first call to take!(r) on the client unblocks the remote task. Seems totally reasonable.
@malmaud malmaud closed this on Oct 21, 2015
@amitmurthy
The Julia Language member
amitmurthy commented on Oct 21, 2015

dup of #12392