Issue 3653: Should get/set_slot on PICurrent be disallowed in ORBInitializer? (interceptors-rtf) Source: Oracle (Dr. Harold Carr, Ph.D., nobody) Nature: Uncategorized Issue Severity: Summary: Currently one can write code like post_init(ORBInitInfo info) { PICurrent pic = (narrow ...)info.resolve_initial_references("PICurrent"); SlotId id = info.allocate_slot_id(); pic.set_slot(id, ...); } It would be most efficient if an implementation could wait until after all ORBInitializer complete to allocate a fixed sized slot table. However, the current spec makes it impossible to wait. I do not think there is anything useful you can do via set_slot at this point so disallowing it should not be a problem. Resolution: For performance reasons, we have always wanted a fixed size slot table. Without fixing the problem Revised Text: In document #ptc/2000-04-05, change the following: Append the following sentence to section 21.4.3.1 "get_slot" If get_slot is called from within an ORB initializer (see section 21.7 Registering Interceptors) BAD_INV_ORDER with a minor code of 10 shall be raised. Append the following sentence to section 21.4.3.2 "set_slot" If set_slot is called from within an ORB initializer (see section 21.7 Registering Interceptors) BAD_INV_ORDER with a minor code of 10 shall be raised. Append the following sentences to section 21.7.2.11 "allocate_slot_id": Note that while slot id's can be allocated within an ORB initializer, the slots themselves cannot be initialized. Calling set_slot or get_slot on the PICurrent (see section 21.4 Portable Interceptor Current) within an ORB initializer shall raise a BAD_INV_ORDER with a minor code of 10. Actions taken: May 26, 2000: received issue January 9, 2001: closed issue Discussion: End of Annotations:===== Date: Fri, 26 May 2000 12:40:16 -0700 (PDT) Message-Id: <200005261940.MAA07211@shorter.eng.sun.com> From: Harold Carr To: interceptors-ftf@omg.org, issues@omg.org Subject: Should get/set_slot on PICurrent be disallowed in ORBInitializer? Content-Type: text X-UIDL: !KWd9*A5e9'T; Tue, 6 Jun 2000 18:16:21 -0500 Received: from d54mta03.raleigh.ibm.com (d54mta03.raleigh.ibm.com [9.67.228.35]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id SAA34820 for ; Tue, 6 Jun 2000 18:37:01 -0400 Received: by d54mta03.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568F6.007C3AB9 ; Tue, 6 Jun 2000 18:36:54 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org Message-ID: <852568F6.006994D4.00@d54mta03.raleigh.ibm.com> Date: Tue, 6 Jun 2000 15:13:13 -0400 Subject: Re: Issue 3653 (was Re: Announcement of Interceptors FTF Vote 3) Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: 8K3!!6c-!!!'ad9nRld9 Welcome back, Jishnu. Jishnu Mukerji on 06/06/2000 12:25:14 PM > 3653 - NO > > I don't disagree with the general sentiment of the resolution. However, > the resolution text of 3653 is partly incorrect and partly incomplete. > It is incorrect because the minor code 10 for BAD_INV_ORDER is already > used for something else. According to ptc/2000-04-05, 10 is "Invalid portable interceptor call". Do you disagree that this is an invalid portable interceptor call? I guess it depends on what is meant by "portable interceptor call". I treated it as meaning any call made using an interface in the portable interceptor chapter. If you interpret "portable interceptor call" to literally mean ONLY a request or IOR interceptor call, then I would agree with you. How SHOULD we interpret this? > It is incomplete because an additional change > needs to be spcified in Core Chapter 4 to add a new minor code for > BAD_INV_ORDER together with the explanatory text, and then that > minor > code should be used in the resolution. This assumes that we can't use the minor code as defined. > Also, generally it is better to > use the phrase "standard minor code" rather than just "minor code", > because the actual minor code is obtained by OR-ing the "standard > minor > code" with the OMGVMCID thingy. > OK. I would say this is a friendly amendment. But if you still disagree with me after reading my explanation above, then we can all vote this one down and rewrite the resolution as you suggest. As an aside, I see a couple other places in the PI spec where "minor code" is missing the "standard" adjective. And there are also a few in the greater CORBA spec as well. We could easily address the PI ones here, but should a core issue be raised to capture all of them? Russell Butek butek@us.ibm.com Date: Wed, 07 Jun 2000 10:47:55 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: butek@us.ibm.com Cc: interceptors-ftf@omg.org Subject: Re: Issue 3653 (was Re: Announcement of Interceptors FTF Vote 3) References: <852568F6.006994D4.00@d54mta03.raleigh.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: g^ld97%3e9DTGe9jUMd9 butek@us.ibm.com wrote: > > Welcome back, Jishnu. Thank you! > Jishnu Mukerji on 06/06/2000 12:25:14 PM > > 3653 - NO > > > > I don't disagree with the general sentiment of the resolution. However, > > the resolution text of 3653 is partly incorrect and partly incomplete. > > It is incorrect because the minor code 10 for BAD_INV_ORDER is already > > used for something else. > > According to ptc/2000-04-05, 10 is "Invalid portable interceptor call". Do > you disagree that this is an invalid portable interceptor call? I guess it > depends on what is meant by "portable interceptor call". I treated it as > meaning any call made using an interface in the portable interceptor > chapter. If you interpret "portable interceptor call" to literally mean > ONLY a request or IOR interceptor call, then I would agree with you. How > SHOULD we interpret this? I agree that "Invalid portable interceptor call" is the right thing. The problem is purely logisitical and there is no reason to vote this resolution down for that reason. The fact is the the minor codes in 00-04-05 that were allocated will have to change to accommodate the whole slew of minor codes that were allocated by the core RTF. So what was 10 will probably become 20-something:-(. The logistical problem is the following. In a published specification it would be inappropriate to include minor codes for things that are not defined in the spec. So the published 2.4 spec must not include the Interceptor minor codes. Unfortunately, I had edited the Interceptors version of the core chapters before the 2.4 version and had forgotten at that point that 2.4 will add a slew of new minor codes. So at the end of the day the fault is mine. Sorry 'bout that. As you can see I am still recovering from my long sojourn.:-( The way to resolve this logistical problem is to reallocate the Interceptor inotrduced minor codes based on the 2.4 version before the final draft of the Interceptor FTF output is published, thus ensuring that the published standard is consistent. Now that the 2.4 version of the Core is finalized, we could publish an interim draft of Core Chapter 4 including the Interceptor changes based on the 2.4 version of Chapter 4, and include in it the right final minor code allocations. > > It is incomplete because an additional change > > needs to be spcified in Core Chapter 4 to add a new minor code for > > BAD_INV_ORDER together with the explanatory text, and then that > > minor > > code should be used in the resolution. > > This assumes that we can't use the minor code as defined. Nah, don't worry about it. Change my vote to YES, and we will fix the mess editorially.:-( > > Also, generally it is better to > > use the phrase "standard minor code" rather than just "minor > > code", > > because the actual minor code is obtained by OR-ing the "standard > > minor > > code" with the OMGVMCID thingy. > > > > OK. I would say this is a friendly amendment. But if you still > > disagree > with me after reading my explanation above, then we can all vote > > this one > down and rewrite the resolution as you suggest. I wouldn't worry about the "standard" thing too much. I just edit the word in whenever I find it missing. I just wanted to bring this subtlety to everyone's attention. > As an aside, I see a couple other places in the PI spec where "minor code" > is missing the "standard" adjective. And there are also a few in the > greater CORBA spec as well. We could easily address the PI ones here, but > should a core issue be raised to capture all of them? That just shows that I haven't quite found all of them yet.:-) The only thing that the Core RTF should address as an issue I think is inserting a sentence or two in the exceptions section of Chapter 4 explaining the specific use of the phrase "standard minor code". As for inserting the word "standard" at the right place.... I don't think that needs an issue. It just needs careful editing. Cheers, Jishnu. From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA14282 for ; Wed, 7 Jun 2000 11:16:03 -0500 Received: from d54mta03.raleigh.ibm.com (d54mta03.raleigh.ibm.com [9.67.228.35]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id LAA27076 for ; Wed, 7 Jun 2000 11:36:44 -0400 Received: by d54mta03.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568F7.0055C0AB ; Wed, 7 Jun 2000 11:36:38 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org Message-ID: <852568F7.00557EAF.00@d54mta03.raleigh.ibm.com> Date: Wed, 7 Jun 2000 11:33:44 -0400 Subject: Re: Issue 3653 (was Re: Announcement of Interceptors FTF Vote 3) Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: NdZ!!b6Be9B6R!!Ho9e9 Jishnu, Just to summarize (and make sure I'm not misreading your note), your concern with 3653 can be addressed editorially. That's fine by me. I've changed your vote to "yes". And for you folks that conditionally voted yes on this issue (Nick, Paul), unless you tell me otherwise, I'll assume your yes votes are now unconditional. The resolution stays as is, no change, and the problem will be addressed editorially at a later date. Russell Butek butek@us.ibm.com Jishnu Mukerji on 06/07/2000 09:47:55 AM Please respond to jis@fpk.hp.com To: Russell Butek/Austin/IBM@IBMUS cc: interceptors-ftf@omg.org Subject: Re: Issue 3653 (was Re: Announcement of Interceptors FTF Vote 3) butek@us.ibm.com wrote: > > Welcome back, Jishnu. Thank you! > Jishnu Mukerji on 06/06/2000 12:25:14 PM > > 3653 - NO > > > > I don't disagree with the general sentiment of the resolution. However, > > the resolution text of 3653 is partly incorrect and partly incomplete. > > It is incorrect because the minor code 10 for BAD_INV_ORDER is already > > used for something else. > > According to ptc/2000-04-05, 10 is "Invalid portable interceptor call". Do > you disagree that this is an invalid portable interceptor call? I guess it > depends on what is meant by "portable interceptor call". I treated it as > meaning any call made using an interface in the portable interceptor > chapter. If you interpret "portable interceptor call" to literally mean > ONLY a request or IOR interceptor call, then I would agree with you. How > SHOULD we interpret this? I agree that "Invalid portable interceptor call" is the right thing. The problem is purely logisitical and there is no reason to vote this resolution down for that reason. The fact is the the minor codes in 00-04-05 that were allocated will have to change to accommodate the whole slew of minor codes that were allocated by the core RTF. So what was 10 will probably become 20-something:-(. The logistical problem is the following. In a published specification it would be inappropriate to include minor codes for things that are not defined in the spec. So the published 2.4 spec must not include the Interceptor minor codes. Unfortunately, I had edited the Interceptors version of the core chapters before the 2.4 version and had forgotten at that point that 2.4 will add a slew of new minor codes. So at the end of the day the fault is mine. Sorry 'bout that. As you can see I am still recovering from my long sojourn.:-( The way to resolve this logistical problem is to reallocate the Interceptor inotrduced minor codes based on the 2.4 version before the final draft of the Interceptor FTF output is published, thus ensuring that the published standard is consistent. Now that the 2.4 version of the Core is finalized, we could publish an interim draft of Core Chapter 4 including the Interceptor changes based on the 2.4 version of Chapter 4, and include in it the right final minor code allocations. > > It is incomplete because an additional change > > needs to be spcified in Core Chapter 4 to add a new minor code for > > BAD_INV_ORDER together with the explanatory text, and then that > > minor > > code should be used in the resolution. > > This assumes that we can't use the minor code as defined. Nah, don't worry about it. Change my vote to YES, and we will fix the mess editorially.:-( > > Also, generally it is better to > > use the phrase "standard minor code" rather than just "minor > > code", > > because the actual minor code is obtained by OR-ing the "standard > > minor > > code" with the OMGVMCID thingy. > > > > OK. I would say this is a friendly amendment. But if you still > > disagree > with me after reading my explanation above, then we can all vote > > this one > down and rewrite the resolution as you suggest. I wouldn't worry about the "standard" thing too much. I just edit the word in whenever I find it missing. I just wanted to bring this subtlety to everyone's attention. > As an aside, I see a couple other places in the PI spec where "minor code" > is missing the "standard" adjective. And there are also a few in the > greater CORBA spec as well. We could easily address the PI ones here, but > should a core issue be raised to capture all of them? That just shows that I haven't quite found all of them yet.:-) The only thing that the Core RTF should address as an issue I think is inserting a sentence or two in the exceptions section of Chapter 4 explaining the specific use of the phrase "standard minor code". As for inserting the word "standard" at the right place.... I don't think that needs an issue. It just needs careful editing. Cheers, Jishnu. Date: Wed, 07 Jun 2000 12:02:26 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: butek@us.ibm.com Cc: interceptors-ftf@omg.org Subject: Re: Issue 3653 (was Re: Announcement of Interceptors FTF Vote 3) References: <852568F7.00557EAF.00@d54mta03.raleigh.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ,F2e9L#"!!*<_d9eKMe9 butek@us.ibm.com wrote: > > Jishnu, > > Just to summarize (and make sure I'm not misreading your note), your > concern with 3653 can be addressed editorially. Yes. People should just be aware that the minor code will change before the final version is published. > That's fine by me. I've changed your vote to "yes". And for you folks > that conditionally voted yes on this issue (Nick, Paul), unless you tell me > otherwise, I'll assume your yes votes are now unconditional. The > resolution stays as is, no change, and the problem will be addressed > editorially at a later date. OK. Jishnu.