Issue 3340: set_servant and null servant (cxx_revision) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com) Nature: Uncategorized Issue Severity: Summary: the text for set_servant doesn't say what should happen if I call set_servant(0). I would suggest to throw BAD_PARAM in this case. Resolution: Revised Text: Actions taken: February 22, 2000: received issue April 10, 2000: moved from Core to C++ RTF Discussion: Transfer to C++ RTF deferred in June 2011 to the next RTF End of Annotations:===== Date: Tue, 22 Feb 2000 07:28:49 +1000 (EST) From: Michi Henning Reply-To: Core Revision Task Force To: Core Revision Task Force cc: issues@omg.org Subject: set_servant and null servant Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: N]J!!>4l!!=d9!!PV2!! Hi, the text for set_servant doesn't say what should happen if I call set_servant(0). I would suggest to throw BAD_PARAM in this case. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Paul Kyzivat To: "'Core Revision Task Force'" Subject: RE: set_servant and null servant Date: Tue, 22 Feb 2000 08:28:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ^aN!!#EEe9V#Od9`9[d9 Michi - 1) I am not if this can even be described in the core, since Servant is native and hence there is no generic meaning of a servant with value zero. So perhaps this needs to be a C++ rtf issue. 2) In C++, setting the servant to zero is essentially the same as putting it back to what it was before it was first set. Being permitted to do this is, in my opinion, a feature rather than an error. Specifically, initialization requires a sequence of steps, such as: - create the POA - create a default servant - set the default servant on the POA - possibly create and activate objects in the POA - get the POA's POAManager - activate the POAManager Eventually I may want to undo all of this. If so, it is convenient to be able to reverse the steps, one by one. (Note, the above is only an example sequence - other sequences are certainly possible depending on your needs.) Paul > -----Original Message----- > From: Michi Henning [mailto:michi@ooc.com.au] > Sent: Monday, February 21, 2000 4:29 PM > To: Core Revision Task Force > Cc: issues@omg.org > Subject: set_servant and null servant > > > Hi, > > the text for set_servant doesn't say what should happen if I call > set_servant(0). I would suggest to throw BAD_PARAM in this case. > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html > Date: Wed, 23 Feb 2000 09:16:50 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: "'Core Revision Task Force'" Subject: RE: set_servant and null servant In-Reply-To: > <9B164B713EE9D211B6DC0090273CEEA9140371@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: X:^d9Y96e92QH!!h39e9 On Tue, 22 Feb 2000, Paul Kyzivat wrote: > 1) I am not if this can even be described in the core, since > Servant is native and hence there is no generic meaning of a servant > with > value zero. So perhaps this needs to be a C++ rtf issue. I think you are right. > 2) In C++, setting the servant to zero is essentially the same as putting it > back to what it was before it was first set. Being permitted to do this is, > in my opinion, a feature rather than an error. Specifically, initialization > requires a sequence of steps, such as: > > - create the POA > - create a default servant > - set the default servant on the POA > - possibly create and activate objects in the POA > - get the POA's POAManager > - activate the POAManager > > Eventually I may want to undo all of this. If so, it is convenient to be > able to reverse the steps, one by one. (Note, the above is only an example > sequence - other sequences are certainly possible depending on your needs.) It seems pointless to "undo" the default servant. That's because invocations on a POA with USE_DEFAULT_SERVANT but no default servant raise OBJ_ADAPTER. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Paul Kyzivat To: "'Core Revision Task Force'" Subject: RE: set_servant and null servant Date: Tue, 22 Feb 2000 20:09:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ,`Z!![o!e9FH*!!H#~e9 > From: Michi Henning [mailto:michi@ooc.com.au] > It seems pointless to "undo" the default servant. That's > because invocations > on a POA with USE_DEFAULT_SERVANT but no default servant > raise OBJ_ADAPTER. Yeah, it is a bit weird. But I think it still makes sense when it is necessary to divide up responsibility. Suppose one piece of code is responsible for creating and destroying POAs, but some other piece of code is responsible for creating the default servant and associating it with the POA. There may be a case when there is a need to destroy the servant before destroying the POA. The code destroying the servant doesn't want to leave a pointer to it in the POA. Sending OBJ_ADAPTER back to some caller is preferable to calling a non-existent servant. Of course normally one would expect the POAManager to be in some state other than active when doing this sort of thing. Date: Wed, 23 Feb 2000 11:52:48 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: "'Core Revision Task Force'" Subject: RE: set_servant and null servant In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA9140375@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: E^bd90'+!!hGDe9[6^!! On Tue, 22 Feb 2000, Paul Kyzivat wrote: > Yeah, it is a bit weird. But I think it still makes sense > when it is necessary to divide up responsibility. > > Suppose one piece of code is responsible for creating and destroying > POAs, > but some other piece of code is responsible for creating the default > servant > and associating it with the POA. > > There may be a case when there is a need to destroy the servant > before destroying the POA. The code destroying the servant doesn't > want to leave a pointer to it in the POA. Sending OBJ_ADAPTER back > to some caller is preferable to calling a non-existent servant. > > Of course normally one would expect the POAManager to be in some > state other > than active when doing this sort of thing. Well, we currently assert in this case when compiled with debug. When compiled without debug, we throw BAD_PARAM when an attempt is made to set the default servant to null. To me, this seems reasonable seeing that a null default servant isn't good for anything. And, as you say, I should probably disable the POAManager first if I want to destroy the default servant before the POA. I'm not hung up on the precise action to be taken when set_servant is called with a null pointer. But I think it would be nice to standardize this simply because, otherwise, I can't write portable code. Another question: what should happen if the POAManager for a POA is in the inactive state and I call set_servant? Doing so indicates almost certainly a programming error (unless the servant is set to null ;-) I don't mind so much what the particular answer is, but again, standardizing this would help with portability... Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Paul Kyzivat To: "'Juergen Boldt'" , orb_revision@emerald.omg.org Subject: RE: issue 3340 -- Core RTF issue Date: Mon, 20 Mar 2000 17:15:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: #E6!!f*"!!EXLe9OFf!! This shouldn't be a Core RTF issue. You can't talk about set_servant(0) in a language independent way. Instead, this ought to be an issue for those language mappings that have a way to represent a null servant. In the case of C++, it seems reasonable to me that this should be valid - putting the POA back into the state it was in after it was created before set_servant was ever called. The same comment is probably applicable in C and Java. Paul > -----Original Message----- > From: Juergen Boldt [mailto:juergen@omg.org] > Sent: Monday, March 20, 2000 4:51 PM > To: issues@emerald.omg.org; orb_revision@emerald.omg.org > Subject: issue 3340 -- Core RTF issue > > > This is issue # 3340 > > set_servant and null servant > > the text for set_servant doesn't say what should happen if I call > set_servant(0). I would suggest to throw BAD_PARAM in this case. > > ================================================================ > > Juergen Boldt > Senior Member of Technical Staff > > Object Management Group Tel. +1-781 444 0404 ext. 132 > 250 First Avenue, Suite 201 Fax: +1-781 444 0320 > Needham, MA 02494, USA Email: juergen@omg.org > > > > ================================================================ > Sender: jis@fpk.hp.com Message-ID: <38F23F7B.DE679E58@fpk.hp.com> Date: Mon, 10 Apr 2000 16:54:19 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.10.10 9000/777) MIME-Version: 1.0 To: juergen@omg.org Cc: cxx_revision@omg.org Subject: issue 3340 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: m@d!!17Q!!hP9e9ic0!! Please move issue 3340 from Core RTF to C++ RTF, as per Core RTF NM Vote 4 results. Thanks, Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Mon, 15 Jan 2001 23:51:37 -0330 From: Matthew Newhook To: cxx_revision@omg.org Subject: issue 3340 Message-ID: <20010115235137.A12469@ooc.com> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.2.5i Content-Type: text/plain; charset=us-ascii X-UIDL: ="`d9K/?!!YWPe9U`l!! Hi, Looking over this archive. There are two proposals: - Throw BAD_PARAM (Michi's proposal) - Clear the default manager (Paul's proposal) I think we should simply have a vote on this issue. I would favour BAD_PARAM since I think it's of dubious value to be able to clear the default servant (in fact, I think it's probably of dubious value to be able to change the default servant once set). Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Tue, 16 Jan 2001 13:03:17 -0800 From: "Andy Cutright" X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: cxx_revision@omg.org Subject: Re: issue 3340 References: <20010115235137.A12469@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: N(O!!MInd9DXGe9-")!! hi all, i agree with BAD_PARAM, cheers, andy Matthew Newhook wrote: > Hi, > > Looking over this archive. There are two proposals: > > - Throw BAD_PARAM (Michi's proposal) > - Clear the default manager (Paul's proposal) > > I think we should simply have a vote on this issue. I would favour > BAD_PARAM since I think it's of dubious value to be able to clear >the > default servant (in fact, I think it's probably of dubious value >to > be able to change the default servant once set). > > Regards, Matthew > -- > Matthew Newhook E-Mail: >mailto:matthew@ooc.com > Software Designer WWW: http://www.ooc.com > Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Thu, 15 Feb 2001 16:33:44 +1000 (EST) From: Michi Henning To: C++ Revision Task Force cc: Jishnu Mukerji Subject: Thoughts on 3340 Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: jSa!!9dg!!NGbd9A#Y!! Hi, I was ready to write up a nifty little proposal for 3340 (raise BAD_PARAM for attempts to set the default servant to null or to change the default servant). Then I checked the core spec. I'm doubtful that this is something that we should deal with as part of the C++ RTF alone. Here are the concerns: The proposal was to raise BAD_PARAM for setting the default servant to null and for attempting to change the default servant. I agree with this, because I can't see a valid use case. However, the core makes no mention of it being illegal to change the default servant. In the absence of words to the contrary, we therefore have to assume that it is legal. Also, the core makes no mention of attempts to set the default servant to nul. That's understandable, given that type Servant may not even be something that supports the concept of null. I also looked at the IDL for the core and checked all the places where Servant is used (raises expressions omitted): Servant incarnate(...); void etherealize(..., in Servant s, ...); Servant preinvoke(...); void postinvoke(..., in Servant s); Servant get_servant(); void set_servant(in Servant s); ObjectId activate_object(in Servant s); void activate_object_with_id(..., in Servant s); ObjectId servant_to_id(in Servant s); Object servant_to_reference(in Servant s); Servant reference_to_servant(...); Servant id_to_servant(...); The core doesn't state for any of these what should happen if a nil reference (or the language mapping's equivalent of nil) is passed, and it does not state what should happen if nil is returned from incarnate() and preinvoke(). For set_servant(), the spec also doesn't say whether I can call that twice. So, I think we need to clean this up: - The following operations are called by the application and expect a Servant parameter: void set_servant(in Servant s); ObjectId activate_object(in Servant s); void activate_object_with_id(..., in Servant s); ObjectId servant_to_id(in Servant s); Object servant_to_reference(in Servant s); We need to somehow say whether it's legal to pass nil to any of these. For set_servant, we also need to say whether I can call it more than once. - The following operations are provided by the application, called by the ORB, and return a servant: Servant incarnate(...); Servant preinvoke(...); We need to say what happens if the application returns a nil servant. - The following operations are called by the application and return a servant: Servant get_servant(); Servant reference_to_servant(...); Servant id_to_servant(...); Servant reference_to_servant(...); Servant id_to_servant(...); We need to say what under what circumstances (if any) the ORB can return a nil servant for these. The reason I feel that this should be part of the core is that it affects implementations (both applications and the ORB). For applications, if one ORB, for example, permits changing the default servant and another ORB doesn't we have a portability problem. This affects more than one language. For example, we have lots of code where C++ and Java directly mirror each other and are almost identical. If it's legal in Java to change the servant but it's illegal in C++, that doesn't work. I'm concerned about implementation issues in the ORB. For example, if it's legal to change the default servant, I can potentially do this while operations are executing in the previous default servant (if I'm threaded). How does the ORB guarantee that, for example, the calls to _add_ref() and _remove_ref() are always done on the correct servant? (I'm sure it's possible to guard against this in the ORB, but why should it be necessary?) So, before writing up a proposal, I'd like to get some feedback. I'm concerned that, if we don't handle this in the core, we end up with subtle differences in POA features across different languages, which is bad. Cheers, Michi. -- Michi Henning +61 7 3324 9633 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 8 Martha St +61 7 3324 9799 (fax) Camp Hill 4152 michi@ooc.com.au Brisbane, AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html