Issue 1735: Servant management rules (cxx_revision) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: Here is a list of all the POA-related operations that deal with the Servant type, and how I believe they need to act with respect to reference counting. Because there aren"t that many operations in this list, I believe that by spelling them out in detail rather than trying to capture their behavior in general rules accomplishes two things: 1) We make it crystal clear to POA implementors and application developers how each operation handles reference counting for the Servants it deals with, and how the POA interacts with those servants. 2) We make it clear to future maintainers of the C++ mapping for the PortableServer module that any new operations that deal with servants must have their servant reference counting semantics explicitly specified. Again, because there are so few operations to cover, explicitly specifying rules for each one is simple and precise. Resolution: Revised Text: Actions taken: July 25, 1998: received issue August 5, 1998: closed issue Discussion: End of Annotations:===== Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Sat, 25 Jul 1998 14:51:33 -0400 To: cxx_revision@omg.org From: Steve Vinoski Subject: Servant management rules Here is a list of all the POA-related operations that deal with the Servant type, and how I believe they need to act with respect to reference counting. Because there aren't that many operations in this list, I believe that by spelling them out in detail rather than trying to capture their behavior in general rules accomplishes two things: 1) We make it crystal clear to POA implementors and application developers how each operation handles reference counting for the Servants it deals with, and how the POA interacts with those servants. 2) We make it clear to future maintainers of the C++ mapping for the PortableServer module that any new operations that deal with servants must have their servant reference counting semantics explicitly specified. Again, because there are so few operations to cover, explicitly specifying rules for each one is simple and precise. --steve * ServantActivator::incarnate -- returns a Servant. The POA does not increment or decrement the reference count of the Servant returned from this function. * ServantActivator::etherealize -- has an in Servant argument. Despite the argument direction, the POA assumes that etherealize consumes the Servant argument, and does not access a Servant in any way after it has been passed to etherealize. A conforming implementation of etherealize may delete its Servant argument if the type of the Servant uses the default reference counting inherited from ServantBase and the Servant has been heap-allocated. * ServantLocator::preinvoke -- returns a Servant. The POA does not increment or decrement the reference count of the Servant returned from this function. * ServantLocator::postinvoke -- has an in Servant argument. Despite the argument direction, the POA assumes that postinvoke consumes the Servant argument, and does not access a Servant in any way after it has been passed to postinvoke. A conforming implementation of postinvoke may delete its Servant argument if the type of the Servant uses the default reference counting inherited from ServantBase and the Servant has been heap-allocated. * POA::get_servant -- returns a Servant. The POA invokes _add_ref once on the Servant before returning it. The caller of get_servant is responsible for ensuring that _remove_ref is invoked once on the returned Servant when it is finished with it. * POA::set_servant -- has an in Servant argument. The implementation of set_servant will invoke _add_ref at least once on the Servant argument before returning. When the POA no longer needs the Servant, it will invoke _remove_ref on it the same number of times. * POA::activate_object -- has an in Servant argument. The implementation of activate_object will invoke _add_ref at least once on the Servant argument before returning. When the POA no longer needs the Servant, it will invoke _remove_ref on it the same number of times. * POA::activate_object_with_id -- has an in Servant argument. The implementation of activate_object_with_id will invoke _add_ref at least once on the Servant argument before returning. When the POA no longer needs the Servant, it will invoke _remove_ref on it the same number of times. * POA::servant_to_id -- has an in Servant argument. The POA does not increment or decrement the reference count of the Servant passed to this function. * POA::servant_to_reference -- has an in Servant argument. The POA does not increment or decrement the reference count of the Servant passed to this function. * POA::reference_to_servant -- returns a Servant. The POA invokes _add_ref once on the Servant before returning it. The caller of reference_to_servant is responsible for ensuring that _remove_ref is invoked once on the returned Servant when it is finished with it. * POA::id_to_servant -- returns a Servant. The POA invokes _add_ref once on the Servant before returning it. The caller of id_to_servant is responsible for ensuring that _remove_ref is invoked once on the returned Servant when it is finished with it. Return-Path: Sender: jon@floorboard.com Date: Sat, 25 Jul 1998 12:53:03 -0700 From: Jonathan Biggar To: Steve Vinoski CC: cxx_revision@omg.org Subject: Re: Servant management rules References: <199807251853.OAA18158@boston.iona.ie> Steve Vinoski wrote: > > Here is a list of all the POA-related operations that deal with the > Servant > type, and how I believe they need to act with respect to reference > counting. Because there aren't that many operations in this list, I > believe > that by spelling them out in detail rather than trying to capture > their > behavior in general rules accomplishes two things: > > 1) We make it crystal clear to POA implementors and application > developers > how each operation handles reference counting for the Servants it > deals > with, and how the POA interacts with those servants. > > 2) We make it clear to future maintainers of the C++ mapping for the > PortableServer module that any new operations that deal with > servants must > have their servant reference counting semantics explicitly > specified. > > Again, because there are so few operations to cover, explicitly > specifying > rules for each one is simple and precise. These look right to me. Thanks Steve! I support making this part of the proposal. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Sun, 26 Jul 1998 07:22:29 +1000 (EST) From: Michi Henning To: Steve Vinoski cc: cxx_revision@omg.org Subject: Re: Servant management rules On Sat, 25 Jul 1998, Steve Vinoski wrote: > Here is a list of all the POA-related operations that deal with the Servant > type, and how I believe they need to act with respect to reference > counting. Because there aren't that many operations in this list, I believe > that by spelling them out in detail rather than trying to capture their > behavior in general rules accomplishes two things: I really like this. Clean, clear, and understandable. Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Date: Sat, 25 Jul 1998 15:13:01 -0700 From: "Jon Goldberg" Reply-To: goldberg@inprise.com To: Steve Vinoski CC: cxx_revision@omg.org Subject: Re: Servant management rules References: thanks, Steve. It looks like this approach is going to work better than what I had before. additional comments below... Steve Vinoski wrote: > > Here is a list of all the POA-related operations that deal with the > Servant > type, and how I believe they need to act with respect to reference > counting. Because there aren't that many operations in this list, I > believe > that by spelling them out in detail rather than trying to capture > their > behavior in general rules accomplishes two things: > > 1) We make it crystal clear to POA implementors and application > developers > how each operation handles reference counting for the Servants it > deals > with, and how the POA interacts with those servants. > > 2) We make it clear to future maintainers of the C++ mapping for the > PortableServer module that any new operations that deal with > servants must > have their servant reference counting semantics explicitly > specified. > > Again, because there are so few operations to cover, explicitly > specifying > rules for each one is simple and precise. > > --steve > > * ServantActivator::incarnate -- returns a Servant. The POA does not > increment or decrement the reference count of the Servant returned > from > this function. > > * ServantActivator::etherealize -- has an in Servant > argument. Despite the > argument direction, the POA assumes that etherealize consumes the > Servant > argument, and does not access a Servant in any way after it has been > passed > to etherealize. A conforming implementation of etherealize may > delete its > Servant argument if the type of the Servant uses the default > reference > counting inherited from ServantBase and the Servant has been > heap-allocated. there should be some mention of caution here that explicit deletion can break any code that (a) has obtained a Servant through invocations of *_to_servant; (b) shares Servants across POAs > * ServantLocator::preinvoke -- returns a Servant. The POA does not > increment or decrement the reference count of the Servant returned > from > this function. > > * ServantLocator::postinvoke -- has an in Servant argument. Despite > the > argument direction, the POA assumes that postinvoke consumes the > Servant > argument, and does not access a Servant in any way after it has been > passed > to postinvoke. A conforming implementation of postinvoke may delete > its > Servant argument if the type of the Servant uses the default > reference > counting inherited from ServantBase and the Servant has been > heap-allocated. > same comment as above for etherealize Return-Path: Sender: jon@floorboard.com Date: Sat, 25 Jul 1998 16:03:47 -0700 From: Jonathan Biggar To: goldberg@inprise.com CC: Steve Vinoski , cxx_revision@omg.org Subject: Re: Servant management rules References: <35BA586D.190FBA53@inprise.com> Jon Goldberg wrote: > > * ServantActivator::etherealize -- has an in Servant argument. Despite the > > argument direction, the POA assumes that etherealize consumes the Servant > > argument, and does not access a Servant in any way after it has been passed > > to etherealize. A conforming implementation of etherealize may delete its > > Servant argument if the type of the Servant uses the default reference > > counting inherited from ServantBase and the Servant has been > > heap-allocated. > > there should be some mention of caution here that explicit deletion > can break any code that (a) has obtained a Servant through > invocations of *_to_servant; (b) shares Servants across POAs > Perhaps a simpler caution is to state that an implementation of etheralize that deletes its servant must ensure that the servant is still in use by another thread or POA. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Sat, 25 Jul 1998 16:26:54 -0700 From: "Jon Goldberg" Reply-To: goldberg@inprise.com To: Jonathan Biggar CC: Steve Vinoski , cxx_revision@omg.org Subject: Re: Servant management rules References: <35BA586D.190FBA53@inprise.com> <35BA6453.CFF721EE@floorboard.com> Jonathan Biggar wrote: > > Jon Goldberg wrote: > > > > * ServantActivator::etherealize -- has an in Servant > argument. Despite the > > > argument direction, the POA assumes that etherealize consumes > the Servant > > > argument, and does not access a Servant in any way after it has > been passed > > > to etherealize. A conforming implementation of etherealize may > delete its > > > Servant argument if the type of the Servant uses the default > reference > > > counting inherited from ServantBase and the Servant has been > > > heap-allocated. > > > > there should be some mention of caution here that explicit > deletion > > can break any code that (a) has obtained a Servant through > > invocations of *_to_servant; (b) shares Servants across POAs > > > > Perhaps a simpler caution is to state that an implementation of > etheralize that deletes its servant must ensure that the servant is > still in use by another thread or POA. only if we want to guarantee they crash :) sure, simpler is better. Cautioning to say that it must ensure the servant is NOT still in use by another thread or POA would be fine with me. -Jon Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Sat, 25 Jul 1998 19:30:43 -0400 To: goldberg@inprise.com From: Steve Vinoski Subject: Re: Servant management rules Cc: cxx_revision@omg.org References: At 03:13 PM 7/25/98 -0700, Jon Goldberg wrote: >thanks, Steve. It looks like this approach is >going to work better than what I had before. > >additional comments below... > >Steve Vinoski wrote: >> * ServantActivator::etherealize -- has an in Servant argument. Despite the >> argument direction, the POA assumes that etherealize consumes the Servant >> argument, and does not access a Servant in any way after it has been passed >> to etherealize. A conforming implementation of etherealize may delete its >> Servant argument if the type of the Servant uses the default reference >> counting inherited from ServantBase and the Servant has been >> heap-allocated. > >there should be some mention of caution here that explicit deletion >can break any code that (a) has obtained a Servant through >invocations of *_to_servant; (b) shares Servants across POAs You're right -- how about we add the following: However, beware that explicitly deleting the Servant argument may result in memory access violations or other serious errors, depending on the nature of the application. For example, if the same Servant instance was obtained from POA::reference_to_servant or POA::id_to_servant (perhaps in another thread), the caller that obtained the Servant instance may still be using it. Also, deletion may cause problems if the same Servant instance is registered in multiple POAs. >> * ServantLocator::preinvoke -- returns a Servant. The POA does not >> increment or decrement the reference count of the Servant returned >> from >> this function. >> >> * ServantLocator::postinvoke -- has an in Servant argument. Despite >> the >> argument direction, the POA assumes that postinvoke consumes the >> Servant >> argument, and does not access a Servant in any way after it has >> been passed >> to postinvoke. A conforming implementation of postinvoke may delete >> its >> Servant argument if the type of the Servant uses the default >> reference >> counting inherited from ServantBase and the Servant has been >> heap-allocated. >> > >same comment as above for etherealize Same answer. :-) I think the way I would arrange this in the spec is to put the warning paragraph in a single place, perhaps in its own subsection, and then cross-reference it from the etherealize and postinvoke Servant management descriptions. --steve Return-Path: Sender: jon@floorboard.com Date: Sat, 25 Jul 1998 18:24:51 -0700 From: Jonathan Biggar To: goldberg@inprise.com CC: Steve Vinoski , cxx_revision@omg.org Subject: Re: Servant management rules References: <35BA586D.190FBA53@inprise.com> <35BA6453.CFF721EE@floorboard.com> <35BA69BE.62C94F67@inprise.com> Jon Goldberg wrote: > > Jonathan Biggar wrote: > > > > Jon Goldberg wrote: > > > > > > * ServantActivator::etherealize -- has an in Servant > argument. Despite the > > > > argument direction, the POA assumes that etherealize consumes > the Servant > > > > argument, and does not access a Servant in any way after it > has been passed > > > > to etherealize. A conforming implementation of etherealize may > delete its > > > > Servant argument if the type of the Servant uses the default > reference > > > > counting inherited from ServantBase and the Servant has been > > > > heap-allocated. > > > > > > there should be some mention of caution here that explicit > deletion > > > can break any code that (a) has obtained a Servant through > > > invocations of *_to_servant; (b) shares Servants across POAs > > > > > > > Perhaps a simpler caution is to state that an implementation of > > etheralize that deletes its servant must ensure that the servant > is > > still in use by another thread or POA. > > only if we want to guarantee they crash :) > > sure, simpler is better. Cautioning to say that it must > ensure the servant is NOT still in use by another thread or POA > would be fine with me. Sorry, meant not still in use!!! -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Sun, 26 Jul 1998 23:32:56 -0700 (PDT) From: Joachim Achtzehnter Sender: joachim@wizard.kraut.bc.ca To: Steve Vinoski cc: goldberg@inprise.com, cxx_revision@omg.org Subject: Re: Servant management rules On Sat, 25 Jul 1998, Steve Vinoski wrote: > You're right -- how about we add the following: > > However, beware that explicitly deleting the Servant argument may > result in > memory access violations or other serious errors, depending on the > nature > of the application. For example, if the same Servant instance was > obtained > from POA::reference_to_servant or POA::id_to_servant (perhaps in > another > thread), the caller that obtained the Servant instance may still be > using > it. Also, deletion may cause problems if the same Servant instance > is > registered in multiple POAs. Jon Biggar's suggestion to just say that one must ensure no other thread uses the Servant is easier to understand, more to the point, shorter, and more likely to remain true in future revisions... Joachim -- private: joachim@kraut.bc.ca (http://www.kraut.bc.ca) work: joachim@mercury.bc.ca (http://www.mercury.bc.ca)