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    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  Clanguage 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