| 1 | I'm just going to stick some stuff here to help anyone trying
|
|---|
| 2 | to hack the POA. I'll also try and keep it up to date ;)
|
|---|
| 3 |
|
|---|
| 4 | Mark.
|
|---|
| 5 |
|
|---|
| 6 | CORBA object and servant life cycles
|
|---|
| 7 | ====================================
|
|---|
| 8 |
|
|---|
| 9 | Here's a nice diagram from 'Advanced CORBA Porgamming with
|
|---|
| 10 | C++' by Henning and Vinoski.
|
|---|
| 11 |
|
|---|
| 12 | +---------------------------+
|
|---|
| 13 | | |
|
|---|
| 14 | | Object Exists |
|
|---|
| 15 | | |
|
|---|
| 16 | | +------------------+ |
|
|---|
| 17 | | | Object | |
|
|---|
| 18 | | | Activated | |
|
|---|
| 19 | | | +--------------+ | |
|
|---|
| 20 | | | | Servant | | |
|
|---|
| 21 | | | | Incarnated | | |
|
|---|
| 22 | | | +--------------+ | |
|
|---|
| 23 | | +------------------+ |
|
|---|
| 24 | | ^ | |
|
|---|
| 25 | +--------------+ Creation | | | | Destruction +--------------+
|
|---|
| 26 | | Object |--------->| Activate Deactivate |------------>| Object |
|
|---|
| 27 | | Non-existent | | | | | | Non-existent |
|
|---|
| 28 | +--------------+ | | | | +--------------+
|
|---|
| 29 | | | v |
|
|---|
| 30 | | +------------------+ |
|
|---|
| 31 | | | +--------------+ | |
|
|---|
| 32 | | | | Servant | | |
|
|---|
| 33 | | | | Etherealized | | |
|
|---|
| 34 | | | +--------------+ | |
|
|---|
| 35 | | | Object | |
|
|---|
| 36 | | | Deactivated | |
|
|---|
| 37 | | +------------------+ |
|
|---|
| 38 | | |
|
|---|
| 39 | +---------------------------+
|
|---|
| 40 |
|
|---|
| 41 | The key points are :
|
|---|
| 42 |
|
|---|
| 43 | * once an object reference has been created the object exists.
|
|---|
| 44 | * once it exists it can either be activated or deactivated.
|
|---|
| 45 | * to be activated it must be incarnated by a servant - i.e. a
|
|---|
| 46 | servant must be associated with object.
|
|---|
| 47 | * to be deactivated the servant must be etherealised - i.e.
|
|---|
| 48 | the bond between the servant and object broken.
|
|---|
| 49 | * activate and deacitvate apply to objects, incarnate and
|
|---|
| 50 | etherealise apply to servants.
|
|---|
| 51 |
|
|---|
| 52 | ORBit's implementation
|
|---|
| 53 | ======================
|
|---|
| 54 |
|
|---|
| 55 | In ORBit and object reference is represented by a
|
|---|
| 56 | CORBA_Object and, within the POA, by a POAObject. Every CORBA_Object
|
|---|
| 57 | created by the POA has a POAObject associated with it.
|
|---|
| 58 |
|
|---|
| 59 | When a POAObject is created it is entered into its POA's
|
|---|
| 60 | .oid_obj_map, a hash table with ObjectIds as keys and POAObjects as
|
|---|
| 61 | values.
|
|---|
| 62 |
|
|---|
| 63 | When an object is activated by the POA, it is associated with
|
|---|
| 64 | a servant by setting its POAObject .servant member. The POAObject is
|
|---|
| 65 | also entered into a list of POAObjects in the servant's ._private
|
|---|
| 66 | member. The reverse is done when the object is deactivated.
|
|---|
| 67 |
|
|---|
| 68 | The CORBA spec talks about an 'Active Object Map'. The idea is
|
|---|
| 69 | that if the POA has the RETAIN policy it stores the association
|
|---|
| 70 | between object id and servant in this Active Object Map when it is
|
|---|
| 71 | activated. In ORBit, there is no explicit Active Object Map. An object
|
|---|
| 72 | can be thought of being entered in the POA's Active Object Map once it has
|
|---|
| 73 | been entered in the POA's .oid_to_obj_map hash table (when the
|
|---|
| 74 | POAObject is created) and the POAOjbect's .servant is non-NULL (when
|
|---|
| 75 | the object is activated).
|
|---|
| 76 |
|
|---|
| 77 | POA refcounting
|
|---|
| 78 | ===============
|
|---|
| 79 |
|
|---|
| 80 | When talking about refcounting, I mean internal refs - i.e
|
|---|
| 81 | ORBit_RootOject_duplicate as opposed to CORBA_Object_duplicate - the
|
|---|
| 82 | application can also be responsible for refs to the POA.
|
|---|
| 83 |
|
|---|
| 84 | * ORBit_POA_new - we're creating a POA, set the initial
|
|---|
| 85 | refcount to 1. This ref is released in ORBit_POA_destroy.
|
|---|
| 86 |
|
|---|
| 87 | * ORBit_POA_add_child - we're associating the POA with its
|
|---|
| 88 | parent. The ref is released ORBit_POA_remove_child when the
|
|---|
| 89 | POA is being destoryed.
|
|---|
| 90 |
|
|---|
| 91 | * ORBit_POA_create_object - we're assoiciating a POA with a
|
|---|
| 92 | POAObject. The ref is released in ORBit_POAObject_release_cb
|
|---|
| 93 | when the POAObject is being destroyed.
|
|---|
| 94 |
|
|---|
| 95 | * ORBit_init_internals - this is *only* for the RootPOA. We
|
|---|
| 96 | don't want the RootPOA to be destroyed until, at the earliest,
|
|---|
| 97 | the ORB has been destroyed. So, this ref is released in
|
|---|
| 98 | CORBA_ORB_destroy.
|
|---|
| 99 |
|
|---|
| 100 | POAObject refcounting
|
|---|
| 101 | =====================
|
|---|
| 102 |
|
|---|
| 103 | * ORBit_POA_activate_object - ref released in
|
|---|
| 104 | ORBit_POA_deactivate.
|
|---|
| 105 |
|
|---|
| 106 | * ORBit_POA_obj_to_ref - we're creating a CORBA_Object and
|
|---|
| 107 | associating the POAObject with it. The ref is released in
|
|---|
| 108 | CORBA_Object_release_cb when the object reference is being
|
|---|
| 109 | destoryed.
|
|---|
| 110 |
|
|---|
| 111 | * ORBit_POA_ServantManager_use_servant - we're using a servant
|
|---|
| 112 | manager to activate an object. In both the RETAIN and
|
|---|
| 113 | NON-RETAIN cases we ref the POAObject. In the RETAIN case this
|
|---|
| 114 | ref is released by ORBit_POA_deactivate. In the NON-RETAIN
|
|---|
| 115 | case the ref is released by unuse_servant.
|
|---|
| 116 |
|
|---|
| 117 | MULTIPLE_ID POAs
|
|---|
| 118 | ================
|
|---|
| 119 |
|
|---|
| 120 | So that a servant can incarnate more than one object, the
|
|---|
| 121 | ORBit_POAObject pointed to by the servant's ._private member has a
|
|---|
| 122 | .next member pointing to the next Object incarnated by that servant.
|
|---|
| 123 | This forms a simple singly-linked list of Objects. A GSList was not
|
|---|
| 124 | used so as to not kill the common case of a UNIQUE_ID POA.
|
|---|
| 125 |
|
|---|
| 126 | If you look at the note at the end of section 11.3.5.1, it
|
|---|
| 127 | says that it is legal for the servant to be shared between two POAs
|
|---|
| 128 | with different Object Id uniqueness policies.
|
|---|
| 129 |
|
|---|
| 130 | This could create serious problems when we are using
|
|---|
| 131 | obtaining the POAObject associated with the servant in the UNIQUE_ID
|
|---|
| 132 | case. This needs to fixed to check that it actually belongs to the POA
|
|---|
| 133 | in question.
|
|---|
| 134 |
|
|---|
| 135 | Implementing Another Object Adaptor
|
|---|
| 136 | ==================================
|
|---|
| 137 |
|
|---|
| 138 | ORBit2's POA is virtualised. This means that, in theory, it
|
|---|
| 139 | should be possible to plug another Object Adaptor into the ORB. The
|
|---|
| 140 | details are in orbit/poa/orbit-adaptor.h.
|
|---|
