You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It looks like n-t-tcp does not implement heartbeats, nor does the n-t documentation ask for that. Yet, spawn seems to rely on monitoring to learn of disconnections.
spawn uses delay, which won't run the spawned process unless it gets either a monitor notification or an ack from the caller. On the other hand, the caller can complete the call to spawn before the ack to delay arrives. If a disconnection occurs at this point, the spawned process will block indefinitely.
A simple fix is to stop using delay, and ask the user to take extra precautions if the spawned action is killing the remote node.
A simple workaround is to have the user use spawnAsync directly.
If call starts using cpDelayed as proposed in #183, the spawned process could block indefinitely if there is a disconnection. The call to call would not complete, but there wouldn't be a way to interrupt it while avoiding leaking the spawned process.
A fix for this could be to give up monitoring the spawned process and avoid using cpDelayed.
Thoughts?
The text was updated successfully, but these errors were encountered:
qnikst
changed the title
[DP-104]
[DP-104]spawn without hearbeats
Jun 16, 2015
[Imported from JIRA. Reported by Facundo Dominguez @facundominguez) as DP-104 on 2015-02-24 11:57:14]
by Facundo Dominguez at https://cloud-haskell.atlassian.net/browse/DP-104:
It looks like n-t-tcp does not implement heartbeats, nor does the n-t documentation ask for that. Yet, spawn seems to rely on monitoring to learn of disconnections.
spawn
usesdelay
, which won't run the spawned process unless it gets either a monitor notification or an ack from the caller. On the other hand, the caller can complete the call tospawn
before the ack todelay
arrives. If a disconnection occurs at this point, the spawned process will block indefinitely.A simple fix is to stop using
delay
, and ask the user to take extra precautions if the spawned action is killing the remote node.A simple workaround is to have the user use spawnAsync directly.
If call starts using
cpDelayed
as proposed in #183, the spawned process could block indefinitely if there is a disconnection. The call to call would not complete, but there wouldn't be a way to interrupt it while avoiding leaking the spawned process.A fix for this could be to give up monitoring the spawned process and avoid using
cpDelayed
.Thoughts?
The text was updated successfully, but these errors were encountered: