GitLab

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.

Sending and recving on the same RP can cause a logical race where the
sender receives their own capability instead of the capability they were
trying to obtain from the other end. The functions (and class) added in
this commit allow you to bootstrap an RP into two RPs that can be used
exclusively for sending or recving, thus avoiding the logical race.

This reverts commit d82aab8f.

Previously, the cn_node_new would put the rp0 in the node's
actual c-space, and the reset operation would put it in the node's
secret c-space. Which meant that if the rp0 was fetched *after* the node
was reset, it wouldn't function properly (since the capability would not
be valid in the node's real principal).

This commit fixes the implementation of rp0 to always put the rp0 in
the secret c-space. This is probably a good idea to ensure that CapNet
can always safely revoke the rp0 when the node is reset, but I believe
the previous implementation was still safe. So now, when the node calls
the `rp0` rpc, the node is explicitly granted its own rp0 from its secret
principal.

This commit also fixes an improper-free bug after a principal is
cleared. When the principal is cleared its refcount would be set to zero
(due to a cal to _obj_init) instead of keeping the same refcount it had
before the clear operation.

By setting the hold debugging flags to true or false you can
get logging information each time a lock is held or released.

Previously, if the timeout has not explicitly negative or None, the
receiver would still try at least twice to get the data. With a timeout
of 0, it will work basically the same as a nowait.

Well, for now, the id is the port id... will need to split that out
separately later on.

Previously, it was manually constructing the rp_elems and using
`cn_rp_send_elem` which would assume that the caller had set the send
type appropriately, dispatch was never updated to deal with membrane
types, this commit fixes that.

This function previously would only lock the csw and cport associated
with the new node, but it didn't actually lock the node -- it left that
to others.  I see no reason to allow that to continue; we're going to
lock it shortly anyway.  And this will prevent contention in the new
node path vs ARPs for or from this node in the packet_in path; that is
what I thought the original problem in #6 was --- no longer sure if that
really was it.  Still, this is an improvement, I believe.

The DHCP and OS meta flow setup functions were locking in the wrong
order.  They would try to grab the cn_node_t lock associated with the
dhcp server cn_node_t and the osmeta server cn_node_t first, then do
some flow setup work that would result in the csw lock associated with
both of those nodes being taken.  The order is always csw, cport,
cnode.  So now these functions follow that convention, and things are
happy.

This would typically manifest when a new node was entering from the
metadata server (always from the pending list, as I saw it), and
conflicting with a packet in msg (i.e., an ARP involving the DHCP server
or the OS metadata server).

This should avoid races between node creation and when a node actually
gets its `me` capability delivered.

Specifically, it logs the type of the object the request wants CapNet to
create.