Skip to content

A closeLocalNode that cleans up after itself #188

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 7 commits into from
Jun 19, 2015
Merged

A closeLocalNode that cleans up after itself #188

merged 7 commits into from
Jun 19, 2015

Conversation

mboes
Copy link
Contributor

@mboes mboes commented Mar 7, 2015

closeLocalNode currently closes the network-transport endpoint, but that's about it. Processes that run on the given node still run, it's just that they can no longer be contacted via a network-transport connection. In this PR, we take a page from network-transport-tcp's book and define a node as having two possible states: "valid" and "closed". A node in the "closed" state is defunct, so all resources associated with it can be freed. Moreover, no new processes can be spawned on a closed node without raising an exception.

This PR is an alternative to #187.

Ping @qnikst you said you had tests for this?

Ping @facundominguez

mboes added 3 commits March 7, 2015 20:08
Introduce new LocalNodeClosed state. This is a final state for local
nodes, which they reach when 'closeLocalNode' closes the node.
This is what Erlang does, and arguably the more unsurprising behaviour.
@mboes
Copy link
Contributor Author

mboes commented Mar 8, 2015

If closeLocalNode returns before all processes die, there is no way to know if the transport is being used. This in turn, implies that the transport needs to be made crash free after the endpoint is released

@facundominguez network-transport backends shouldn't just cause the program to segfault if someone attempts to use the transport after it has been closed. network-transport-tcp is safe in this way, using a similar mechanism as in this PR. It's a bug in any network-transport backend that behaves in this way if not, that I don't think it's distributed-process's business to work around. And as noted above, it would be unfortunate to have a call to closeLocalNode hang just because some process messed up its exception handlers.

Opening local nodes is very common for tests. It should be possible to close a local node after a test completes and have all resources allocated during that test (namely processes) reclaimed. This kind of resource reclamation is likely why there was a TODO item associated to this function in the first place, calling for killing the processes. Furthermore, processes become pretty useless once the endpoint is closed: they can't communicate anymore with anyone else (technically they can with other local processes, but that's an implementation detail due to an optimization).

@hyperthunk
Copy link
Member

Reviewing now, so sorry for the delay guys.

@qnikst
Copy link
Contributor

qnikst commented Jun 17, 2015

I'd like to squash and merge this, any objections?

@qnikst qnikst added this to the distributed-process-0.6 milestone Jun 18, 2015
@facundominguez
Copy link
Contributor

LGTM

qnikst added a commit that referenced this pull request Jun 19, 2015
A closeLocalNode that cleans up after itself
@qnikst qnikst merged commit a386058 into haskell-distributed:master Jun 19, 2015
@qnikst
Copy link
Contributor

qnikst commented Jun 19, 2015

Ops.. forgot to squash..

@mboes mboes deleted the localnode-closed-state branch June 19, 2015 15:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants