Commit 61e0295d authored by Josh Kunz's avatar Josh Kunz

Adds destructors to cleanup unreferenced capabilities

When the python object associated with a given capability is garbage collected
(i.e. there are no more references to it), the object will call capnet
to delete the associated capability. Except for flows. Often times,
flows should persist, even after python-level references are lost. They
must be manually managed.
parent cb71a476
Pipeline #2141 passed with stage
in 38 seconds
......@@ -671,6 +671,11 @@ class Capability(object):
def type(self):
return self.__objtype__
def __del__(self):
# Object has no __del__ method, otherwise, we'd have to call it
class Node(Capability):
__objtype__ = cn_pb.CPOBJTYPE_NODE
......@@ -896,6 +901,8 @@ class Membrane(Capability):
class Flow(Capability):
"""Note: Flow Capabilities are not automatically deleted when they go
out of scope, the .delete() method must be called explicitly."""
__objtype__ = cn_pb.CPOBJTYPE_FLOW
def mint(self, *args):
......@@ -908,6 +915,12 @@ class Flow(Capability):
# special stuff in the future
return super(Flow, self).mint()
def __del__(self):
super(Capability, self).__del__()
except AttributeError:
class NodeGrant(Capability):
__objtype__ = cn_pb.CPOBJTYPE_NODE_GRANT
  • Wow, this one slipped by me. Is this really the right behavior? What about workflow agent disconnects?

  • What about workflow agent disconnects?

    This is a case I didn't consider. I'm not sure about that. I think it's definitely not correct to make the user manually garbage-collect their capabilities. A) because we use a lot of capabilities in the workflows, and B) because it's just a very un-python interface.

    Maybe there's a way to preserve this behavior without killing all capabilities when the agent disconnects? Seems kinda gross, so I'm not sure.

  • For now, I'd be happy to resolve it by simply passing a Context or Config object into Protocol() that would expose config bits. Then this auto-delete style could remain the default; but it could be disabled if necessary. Obviously right now there can only be one Protocol() per port, but if we ever had a different Transport you could imagine more than one instance.

Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment