1. 15 Aug, 2017 1 commit
  2. 12 May, 2017 2 commits
    • Josh Kunz's avatar
      Adds destructors to cleanup unreferenced capabilities · 61e0295d
      Josh Kunz authored
      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.
      61e0295d
    • Josh Kunz's avatar
      Add some helpful functions to avoid logical rp races · cb71a476
      Josh Kunz authored
      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.
      cb71a476
  3. 11 May, 2017 9 commits
  4. 09 Mar, 2017 2 commits
  5. 02 Dec, 2016 7 commits
  6. 09 Nov, 2016 1 commit
  7. 20 Oct, 2016 1 commit
  8. 19 Oct, 2016 2 commits
  9. 18 Oct, 2016 5 commits
    • Josh Kunz's avatar
      Make dispatch_invoke of RP_SEND use `cn_rp_send` · 7f3a8bee
      Josh Kunz authored
      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.
      7f3a8bee
    • Josh Kunz's avatar
      Add more detailed membrane logging information · 8e63f304
      Josh Kunz authored
      8e63f304
    • Josh Kunz's avatar
      Log msg UUIDs at "info" level · bb04856c
      Josh Kunz authored
      bb04856c
    • David Johnson's avatar
      Decrease lock contention on new nodes in cnc_port_add (inspired by #6). · 86480b22
      David Johnson authored
      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.
      86480b22
    • David Johnson's avatar
      Fix DHCP/OS metadata flow setup locking issues from issue #6. · 10dc1aa8
      David Johnson authored
      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).
      10dc1aa8
  10. 17 Oct, 2016 1 commit
  11. 13 Oct, 2016 9 commits