Issue 1116: DynAny issues (port-rtf) Source: (, ) Nature: Revision Severity: Summary: Summary: Section 7.1 states: "Destroying a DynAny object implies deleting the buffer it points to and also destroying all DynAny objects obtained from it. Invoking operations using references to descendants of a destroyed DynAny object leads to unpredictable results. Note that releasing a reference to a DynAny object will not delete the buffer pointed by the object, since the object indeed exists (it has not been explicitly destroyed)." This does not seem to completely specify the semantics of how destroying a DynAny affects its semantics. If I have 3 DynAnys, DA1, DA2, and DA3, where I created DA2 from DA1 using current_component(), and DA3 from DA2 also using current_component, what are the effects of the following operations: 1. DA1->destroy() 2. DA2->destroy() 3. DA3->destroy() Resolution: Revised Text: Actions taken: March 30, 1998: received issue June 19, 1998: moved from orb_revision to port-rtf July 30, 1998: closed issue Discussion: End of Annotations:===== Return-Path: Sender: jon@floorboard.com Date: Mon, 30 Mar 1998 22:32:04 -0800 From: Jonathan Biggar To: issues@omg.org, orb_revision@omg.org Subject: DynAny issues Section 7.1 states: "Destroying a DynAny object implies deleting the buffer it points to and also destroying all DynAny objects obtained from it. Invoking operations using references to descendants of a destroyed DynAny object leads to unpredictable results. Note that releasing a reference to a DynAny object will not delete the buffer pointed by the object, since the object indeed exists (it has not been explicitly destroyed)." This does not seem to completely specify the semantics of how destroying a DynAny affects its semantics. If I have 3 DynAnys, DA1, DA2, and DA3, where I created DA2 from DA1 using current_component(), and DA3 from DA2 also using current_component, what are the effects of the following operations: 1. DA1->destroy() 2. DA2->destroy() 3. DA3->destroy() For case 1, it is obvious that all three DynAnys are destroyed, and for case 3 it is obvious that DA3 is the only one destroyed. Case 2 leaves a question: does it have the side effect of destroying DA3, or does DA3 hang around until DA1 is destroyed also? I would prefer that it destroys DA3, but I can see how someone might read it the other way, due to the shared buffer. Also, the language here about deleting the buffer needs to be updated to make it clear that the buffer is actually only deleted when the ultimate parent DynAny is destroyed, not when any DynAny objects created from it are destroyed. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Wed, 01 Jul 1998 14:48:52 -0400 From: Jonathan Biggar Organization: Floorboard Software To: port-rtf@omg.org Subject: Proposal for Issue 1116 Replace the following text in section 7.1: Destroying a DynAny object implies deleting the buffer it points to and also destroying all DynAny objects obtained from it. Invoking operations using references to descendants of a destroyed DynAny object leads to unpredictable results. Note that releasing a reference to a DynAny object will not delete the buffer pointed by the object, since the object indeed exists (it has not been explicitly destroyed). with: Destroying a top level DynAny object (one that was not created as a component of another DynAny) will also destroy the memory buffer associated with the DynAny and any component DynAny objects obtained from it, and will effectively destroy the component DynAny objects. Destroying a non-top level DynAny object will not affect the memory buffer, but will still destroy its component DynAny objects. Invoking operations on a destroyed DynAny or any of its descendants will result in undefined behavior. Note that simply releasing all references to a DynAny object will not delete the DynAny or its buffer; it must be explicitly destroyed to avoid memory leaks. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Thu, 2 Jul 1998 07:39:12 +0100 From: jhierro@jam.tid.es (Juan Jose Hierro Sureda) To: port-rtf@omg.org Subject: Re: Proposal for Issue 1116 X-Sun-Charset: US-ASCII Hi all, I vote yes to adoption of the proposal sent by Jon for issue 1116. I believe it describes more accurately and formally what we had in mind when we developed the spec. Thanks Jon, -- Juanjo > Replace the following text in section 7.1: > > Destroying a DynAny object implies deleting the buffer it points to > and > also > destroying all DynAny objects obtained from it. Invoking operations > using references > to descendants of a destroyed DynAny object leads to unpredictable > results. Note that > releasing a reference to a DynAny object will not delete the buffer > pointed by the > object, since the object indeed exists (it has not been explicitly > destroyed). > > with: > > Destroying a top level DynAny object (one that was not created as a > component of another DynAny) will also destroy the memory buffer > associated with the DynAny and any component DynAny objects obtained > from it, and will effectively destroy the component DynAny objects. > Destroying a non-top level DynAny object will not affect the memory > buffer, but will still destroy its component DynAny objects. > Invoking > operations on a destroyed DynAny or any of its descendants will > result > in undefined behavior. Note that simply releasing all references to > a > DynAny object will not delete the DynAny or its buffer; it must be > explicitly destroyed to avoid memory leaks. > > -- > 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: Fri, 10 Jul 1998 15:36:13 +1000 (EST) From: Michi Henning Reply-To: Michi Henning To: port-rtf@omg.org Subject: 1116 again... I'm currently doing quite a bit of coding with DynAny. I'm running into the need to call destroy() on DynAnys again and again. This just doesn't make sense. It is totally out of synch with how I deal with other pseudo-objects, such as TypeCode and Request. None of the other pseudo-objects require explicit destruction, but DynAny does :-( The inconsistency becomes painfully obvious when you look at the code example on page 7-16. I have to look really hard to see why destroy is not called on the dyn_member variable, but *is* called on the dyn_struct variable. Of course, my reading of the proposed clarification to 1116 suggests that I *could* destroy dyn_member, but it wouldn't have any real effect until after dyn_struct is destroyed. What's the point then of having the call anyway? :-( This is so ugly it isn't funny. I'm currently writing training material for DynAny, and its no fun trying to explain why the programmer has to make a call that adds nothing but noise to the code, let alone trying to explain what the semantics are if I destroy a DynAny in the middle of a hierarchy. It doesn't do CORBA any good if we have APIs that are unnecessarily complex... Proposal: Remove destroy from the DynAny interface. It isn't necessary because the job can be done by the normal duplicate/release semantics on object references. This change would simplify the API and bring it stylistically in line with the other pseudo-objects. Backward compatibility is not a problem. ORBs concerned about that can retain destroy but make it a no-op. Cheers, 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