Skip to content

Race condition on GravityNode deletion #223

Description

@mbarger99

It's possible that subscription data could arrive just as a GravityNode is being deleted. The GravityNode destructor sends a request to kill the SubscriptionManager, but doesn't wait for the manager thread to respond to the request. In this situation, it's possible that the sub manager thread could be processing incoming data (which would block the kill command from being processed), but GravityNode deletion would still complete.

Note that calling GravityNode::unsubscribe does not solve the issue because the unsubscribe call returns without receiving confirmation that the sub manager has deleted the subscription.

I see a couple possible solutions here:

  1. Require the GravityNode user to unsubscribe and unregister everything before deleting a node. This could be cumbersome to use, but seems like the cleanest option
  2. Have the GravityNode destructor wait for a response from each manager thread before returning. This might be the safest catch-all, but it could be problematic to be ready to handle callbacks while the GravityNode is being deleted.

The most complete solution may require both of these.

cc @kguilbert

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Fields

No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions