Issue 735: Ada mapping deficiency - orbos/97-09-26 (3) (ada-rtf) Source: (, ) Nature: Revision Severity: Minor Summary: Summary: Inconsistencies in section 21.5.8 (standard exceptions) and Appendix A1 (package CORBA): Changes to standard exceptions section have not been reflected in Appendix 1A (System_Exception_Members, exception members type) The example exception members type is referred to as Unknown_Members and Unknown_Exception_Members. It is not clear how type Unknown_Members is used Resolution: Accepted, close issue Revised Text: Accept. Actions taken: October 3, 1997: received issue June 4, 1999: closed issue Discussion: received issue End of Annotations:===== Return-Path: Date: Fri, 3 Oct 1997 17:59:17 +0100 (BST) From: David A J Elsworthy To: issues@omg.org Cc: ada-rtf@omg.org, Dave R Stringer , J.J.Currey@nortel.co.uk, Tim.Roberts.3202975@nortel.co.uk, Andrew Harker , David A J Elsworthy Subject: Ada mapping deficiency - 97-09-26 Deficiency : Inconsistencies in section 21.5.8 (standard exceptions) and appendix A1 (package CORBA). Comment : The changes to the standard exceptions section have not been reflected in appendix A1 (System_Exception_Members, exception members type). The example exception members type is referred to as Unknown_Members and Unkown_Exception_Members. It is not clear how type Unknown_Members is used. Return-Path: From: "Daniel R. Frantz" To: Subject: port-rtf Issue 735 proposal Date: Thu, 2 Jul 1998 13:24:41 -0400 X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 The following is a proposal for issue 735. When I got around to putting specific words down, there were a lot more than we had previously discussed, so I'm making sure this is in a separate message to help identify comments on it. Vote if you approve so we can start the tally. If there are any problems, please reply and we'll discuss further. Dan ------------------------------------------------------------ Issue 736: When does ORB::run return. Nature: Clarification Summary: It's specified that operation ORB::run returns when the ORB has shut down. Does this mean that ORB::run returns when ORB::shutdown returns? The behavior is not well specified Resolution: Accepted for CORBA 2.3. Revision: Section 4.9.3 "run", page 4-20. At the end of the first text paragraph add: The ORB is considered to have shut down after ORB::shutdown has been called and the shutdown has completed. Section 4.9.4 "shutdown", page 4-20. Replace the description with the following. This operation instructs the ORB to shut down, that is, to destroy itself. After shut down completes, the ORB reference is no longer valid. Further use of the ORB requires another call on ORB_INIT. Shutting down the ORB causes all object adapters to be shut down, that is, to be destroyed, since they cannot exist in the absence of an ORB. Shut down is complete when all ORB processing (including request processing and object deactivation or other operations associated with object adapters) has completed and the object adapters have been destroyed. In the case of the POA, this means that all object etherializations have finished and root POA has been destroyed (implying that all descendent POAs have also been destroyed). If the wait_for_completion parameter is TRUE, this operation blocks until the shut down is complete. If the wait_for_completion parameter is FALSE, the shut down may not have completed upon return. Return-Path: Date: Thu, 02 Jul 1998 16:04:25 -0400 From: Jonathan Biggar Organization: Floorboard Software To: "Daniel R. Frantz" CC: port-rtf@omg.org Subject: Re: port-rtf Issue 735 proposal References: <00b501bda5de$4ce54ae0$3fc5bdce@idler.beasys.com> I've got a problem with the idea of being able to "resurrect" the ORB by calling ORB_init again after shutting down the ORB. This is a new feature you're "slipping" in that has major ramifications with the way that ORB implementations work, and might require some pretty major changes to ORB implementations in order to comply. I understand that this may be useful in some long-lived environments, but we need to be entirely clear of all of the repercussions. Jon Daniel R. Frantz wrote: > The following is a proposal for issue 735. When I got around to putting > specific words down, there were a lot more than we had previously > discussed, so I'm making sure this is in a separate message to help > identify comments on it. > > Vote if you approve so we can start the tally. If there are any > problems, please reply and we'll discuss further. > > Dan > > ------------------------------------------------------------ > > Issue 736: When does ORB::run return. > Nature: Clarification > > Summary: It's specified that operation ORB::run returns when > the ORB has shut down. Does this mean that ORB::run > returns when ORB::shutdown returns? The behavior is > not well specified > > Resolution: Accepted for CORBA 2.3. > > Revision: Section 4.9.3 "run", page 4-20. At the end of the > first text paragraph add: > > The ORB is considered to have shut down after > ORB::shutdown has been called and the shutdown has > completed. > > Section 4.9.4 "shutdown", page 4-20. Replace the > description with the following. > > This operation instructs the ORB to shut down, > that is, to destroy itself. After shut down > completes, the ORB reference is no longer valid. > Further use of the ORB requires another call on > ORB_INIT. > > Shutting down the ORB causes all object adapters > to be shut down, that is, to be destroyed, since > they cannot exist in the absence of an ORB. Shut > down is complete when all ORB processing > (including request processing and object > deactivation or other operations associated with > object adapters) has completed and the object > adapters have been destroyed. In the case of the > POA, this means that all object etherializations > have finished and root POA has been destroyed > (implying that all descendent POAs have also been > destroyed). > > If the wait_for_completion parameter is TRUE, this > operation blocks until the shut down is complete. > If the wait_for_completion parameter is FALSE, the > shut down may not have completed upon return. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: From: "Daniel R. Frantz" To: "'Jonathan Biggar'" Cc: Subject: RE: port-rtf Issue 735 proposal Date: Thu, 2 Jul 1998 16:50:37 -0400 X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 >I've got a problem with the idea of being able to "resurrect" >the ORB by >calling ORB_init again after shutting down the ORB. This is a >new feature >you're "slipping" in that has major ramifications with the way that ORB >implementations work, and might require some pretty major >changes to ORB >implementations in order to comply. Actually, I wasn't trying to get a new feature in by resurrecting an ORB. The primary goal was to make clear that the old ORB was no longer available. As for resurrecting, I'm not sure that's new. There are already words in chapter 4 saying that multiple calls on ORB_init are legal. What's new is "rundown" which didn't exist before and whose semantics really haven't been defined. That was part of the point of the issue and I was just trying to pick something. Anything. Very truthfully, it wouldn't bother me if we stated that, once run down happens, nothing else can happen. Anybody else have comments? Dan Return-Path: Date: Thu, 02 Jul 1998 19:36:43 -0400 From: Paul H Kyzivat Organization: NobleNet To: Jonathan Biggar CC: "Daniel R. Frantz" , port-rtf@omg.org Subject: Re: port-rtf Issue 735 proposal References: <00b501bda5de$4ce54ae0$3fc5bdce@idler.beasys.com> <359BE7C9.978AD7A9@floorboard.com> Jonathan Biggar wrote: > > I've got a problem with the idea of being able to "resurrect" the > ORB > by > calling ORB_init again after shutting down the ORB. This is a new > feature > you're "slipping" in that has major ramifications with the way that > ORB > implementations work, and might require some pretty major changes to > ORB > implementations in order to comply. > > I understand that this may be useful in some long-lived > environments, > but > we need to be entirely clear of all of the repercussions. > > Jon This doesn't seem like anything new to me. Once an ORB shutdown is complete, things should be back to the same logical state they were prior to the call to ORB_init that created the orb. At that point it is vhard to imagine a reason why calling ORB_init again should not be allowed. When I first saw the specification changes that included ORB_init and shutdonw, this is one of the first tests I imagined subjecting ORBs to :-) Return-Path: Date: Thu, 02 Jul 1998 23:38:43 -0400 From: Bob Kukura Organization: IONA Technologies To: Paul H Kyzivat CC: Jonathan Biggar , "Daniel R. Frantz" , port-rtf@omg.org Subject: Re: port-rtf Issue 735 proposal References: <00b501bda5de$4ce54ae0$3fc5bdce@idler.beasys.com> <359BE7C9.978AD7A9@floorboard.com> <359C198B.6F5AA3B4@noblenet.com> I mostly agree with Dan and Paul on this one. ORB::shutdown() should restore things to the state they were in before the ORB_init() call that created the ORB instance in the first place. I don't think there is any issue with existing references to the old ORB, since the new ORB should have a new distinct reference, even if it has the same id as the old one. ORB is a pseudo-object, remember, so shutdown() doesn't have to actually destroy the instance and/or invalidate the existing references to it. The old ORB instance can be cleaned up when the last reference to it is released. To me, shutdown() needs to atomically do three things: 1) start the process of shutting down the ORB, waiting for completion if requested. 2) unblock any blocked ORB::run() calls. 3) cause a subsequent call with the same ID to ORB_init() to create a new ORB instance rather than return the old instance. Subsequent calls to ORB_init() with the same ID can wait for the shutdown to complete if necessary. The one change that is needed, in my opinion, is to clarify that once shutdown() has been called (i.e. the atomic action above has occured) on an ORB instance, subsequent calls to all operations (or at least run(), shutdown(), work_pending(), and perform_work()) on that ORB instance will raise BAD_INV_ORDER. -Bob Paul H Kyzivat wrote: > > Jonathan Biggar wrote: > > > > I've got a problem with the idea of being able to "resurrect" the > ORB > > by > > calling ORB_init again after shutting down the ORB. This is a new > > feature > > you're "slipping" in that has major ramifications with the way > that > > ORB > > implementations work, and might require some pretty major changes > to > > ORB > > implementations in order to comply. > > > > I understand that this may be useful in some long-lived > environments, > > but > > we need to be entirely clear of all of the repercussions. > > > > Jon > > This doesn't seem like anything new to me. Once an ORB shutdown is > complete, things should be back to the same logical state they were > prior to the call to ORB_init that created the orb. At that point it > is > hard to imagine a reason why calling ORB_init again should not be > allowed. > > When I first saw the specification changes that included ORB_init > and > shutdonw, this is one of the first tests I imagined subjecting ORBs > to > :-) > > > > ------------------------------------------------------------------------ > > Paul Kyzivat > Software Architect > Noblenet Inc. > > Paul Kyzivat > Software Architect > Noblenet Inc. > 337 Turnpike Road Work: 508-229-4662 > Southboro Fax: 508-460-3456 > Massachusetts Home: 508-779-5387 > 01772 Netscape Conference Address > USA Netscape Conference DLS Server > Additional Information: > Last Name Kyzivat > First Name Paul Return-Path: Date: Fri, 03 Jul 1998 00:36:34 -0400 From: Jonathan Biggar Organization: Floorboard Software To: Bob Kukura CC: Paul H Kyzivat , "Daniel R. Frantz" , port-rtf@omg.org Subject: Re: port-rtf Issue 735 proposal References: <00b501bda5de$4ce54ae0$3fc5bdce@idler.beasys.com> <359BE7C9.978AD7A9@floorboard.com> <359C198B.6F5AA3B4@noblenet.com> <359C5243.63A9EC@iona.com> Another problem to consider is that in various parts of the spec (or in language bindings) there is a concept of a "default" ORB. If I shutdown the "default" ORB and recreate it, is it the "default" ORB again, or does another ORB that is running in the same process become the default? This is just another example of why I think this is stickier than you think. Jon Bob Kukura wrote: > I mostly agree with Dan and Paul on this one. ORB::shutdown() should > restore things to the state they were in before the ORB_init() call that > created the ORB instance in the first place. > > I don't think there is any issue with existing references to the old > ORB, since the new ORB should have a new distinct reference, even if it > has the same id as the old one. ORB is a pseudo-object, remember, so > shutdown() doesn't have to actually destroy the instance and/or > invalidate the existing references to it. The old ORB instance can be > cleaned up when the last reference to it is released. > > To me, shutdown() needs to atomically do three things: > > 1) start the process of shutting down the ORB, waiting for completion if > requested. > > 2) unblock any blocked ORB::run() calls. > > 3) cause a subsequent call with the same ID to ORB_init() to create a > new ORB instance rather than return the old instance. > > Subsequent calls to ORB_init() with the same ID can wait for the > shutdown to complete if necessary. > > The one change that is needed, in my opinion, is to clarify that once > shutdown() has been called (i.e. the atomic action above has occured) on > an ORB instance, subsequent calls to all operations (or at least run(), > shutdown(), work_pending(), and perform_work()) on that ORB instance > will raise BAD_INV_ORDER. > > -Bob > > Paul H Kyzivat wrote: > > > > Jonathan Biggar wrote: > > > > > > I've got a problem with the idea of being able to "resurrect" the ORB > > > by > > > calling ORB_init again after shutting down the ORB. This is a new > > > feature > > > you're "slipping" in that has major ramifications with the way that > > > ORB > > > implementations work, and might require some pretty major changes to > > > ORB > > > implementations in order to comply. > > > > > > I understand that this may be useful in some long-lived environments, > > > but > > > we need to be entirely clear of all of the repercussions. > > > > > > Jon > > > > This doesn't seem like anything new to me. Once an ORB shutdown is > > complete, things should be back to the same logical state they were > > prior to the call to ORB_init that created the orb. At that point it is > > hard to imagine a reason why calling ORB_init again should not be > > allowed. > > > > When I first saw the specification changes that included ORB_init and > > shutdonw, this is one of the first tests I imagined subjecting ORBs to > > :-) > > > > ------------------------------------------------------------------------ > > > > Paul Kyzivat > > Software Architect > > Noblenet Inc. > > > > Paul Kyzivat > > Software Architect > > Noblenet Inc. > > 337 Turnpike Road Work: 508-229-4662 > > Southboro Fax: 508-460-3456 > > Massachusetts Home: 508-779-5387 > > 01772 Netscape Conference Address > > USA Netscape Conference DLS Server > > Additional Information: > > Last Name Kyzivat > > First Name Paul -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Fri, 03 Jul 1998 00:34:12 -0400 From: Jonathan Biggar Organization: Floorboard Software To: Paul H Kyzivat CC: "Daniel R. Frantz" , port-rtf@omg.org Subject: Re: port-rtf Issue 735 proposal References: <00b501bda5de$4ce54ae0$3fc5bdce@idler.beasys.com> <359C0A98.FF02344B@noblenet.com> Actually, it should also be adequate if another thread is currently blocked in ORB::run(), because that thread will only unblock when the shutdown is complete. Jon Paul H Kyzivat wrote: > Comments inserted... > > Daniel R. Frantz wrote: > > > > The following is a proposal for issue 735. When I got around to > > putting > > specific words down, there were a lot more than we had previously > > discussed, so I'm making sure this is in a separate message to help > > identify comments on it. > > > > Vote if you approve so we can start the tally. If there are any > > problems, please reply and we'll discuss further. > > > > Dan > > > > ------------------------------------------------------------ > > > > Issue 736: When does ORB::run return. > > Nature: Clarification > > > > Summary: It's specified that operation ORB::run returns when > > the ORB has shut down. Does this mean that ORB::run > > returns when ORB::shutdown returns? The behavior is > > not well specified > > > > Resolution: Accepted for CORBA 2.3. > > > > Revision: Section 4.9.3 "run", page 4-20. At the end of the > > first text paragraph add: > > > > The ORB is considered to have shut down after > > ORB::shutdown has been called and the shutdown has > > completed. > > > > Section 4.9.4 "shutdown", page 4-20. Replace the > > description with the following. > > > > This operation instructs the ORB to shut down, > > that is, to destroy itself. After shut down > > completes, the ORB reference is no longer valid. > > Further use of the ORB requires another call on > > ORB_INIT. > > There is a catch-22 in this: > > If I call orb->shutdown(false), then I am supposed to get control back, > possibly before shutdown is complete, but I have no way to know when > shutdown will be complete. Meanwhile, I have a reference to the ORB that > may or may not be valid. But to complete the shutdown, the ORB may > require access to the main thread, so I may have to call > orb->perform_work to give it the main thread. But, if shutdown has > completed then my orb reference is invalid so I can't use it to call > perform_work... > > This is a real problem in a single threaded orb that has > etherializations to perform. > > I believe the only simple solution to this is to say that an orb is not > shutdown until shutdown(true) has been called and returned. Until then, > calls to shutdown(false) are requests to initiate shutdown, but never > invalidate the reference to the ORB. > > Also, (this has been discussed before) it must be invalid to call > shutdown(true) from an invocation context, since shutdown cannot > complete with an invocation still in progress. > > > > > Shutting down the ORB causes all object adapters > > to be shut down, that is, to be destroyed, since > > they cannot exist in the absence of an ORB. Shut > > down is complete when all ORB processing > > (including request processing and object > > deactivation or other operations associated with > > object adapters) has completed and the object > > adapters have been destroyed. In the case of the > > POA, this means that all object etherializations > > have finished and root POA has been destroyed > > (implying that all descendent POAs have also been > > destroyed). > > > > If the wait_for_completion parameter is TRUE, this > > operation blocks until the shut down is complete. > > If the wait_for_completion parameter is FALSE, the > > shut down may not have completed upon return. > > ------------------------------------------------------------------------ > > Paul Kyzivat > Software Architect > Noblenet Inc. > > Paul Kyzivat > Software Architect > Noblenet Inc. > 337 Turnpike Road Work: 508-229-4662 > Southboro Fax: 508-460-3456 > Massachusetts Home: 508-779-5387 > 01772 Netscape Conference Address > USA Netscape Conference DLS Server > Additional Information: > Last Name Kyzivat > First Name Paul -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Mon, 06 Jul 1998 09:25:25 -0400 From: Paul H Kyzivat Organization: NobleNet To: Bob Kukura CC: Jonathan Biggar , "Daniel R. Frantz" , port-rtf@omg.org Subject: Re: port-rtf Issue 735 proposal References: <00b501bda5de$4ce54ae0$3fc5bdce@idler.beasys.com> <359BE7C9.978AD7A9@floorboard.com> <359C198B.6F5AA3B4@noblenet.com> <359C5243.63A9EC@iona.com> Bob Kukura wrote: > > I mostly agree with Dan and Paul on this one. ORB::shutdown() > should > restore things to the state they were in before the ORB_init() call > that > created the ORB instance in the first place. > > I don't think there is any issue with existing references to the old > ORB, since the new ORB should have a new distinct reference, even if > it > has the same id as the old one. ORB is a pseudo-object, remember, > so > shutdown() doesn't have to actually destroy the instance and/or > invalidate the existing references to it. The old ORB instance can > be > cleaned up when the last reference to it is released. I suppose some cleanup can be left for when the refcount goes to zero, but I would hate to have things arranged so that anything major (like etherealization) had to be done this way. > > To me, shutdown() needs to atomically do three things: > > 1) start the process of shutting down the ORB, waiting for > completion > if > requested. > > 2) unblock any blocked ORB::run() calls. > > 3) cause a subsequent call with the same ID to ORB_init() to create > a > new ORB instance rather than return the old instance. > > Subsequent calls to ORB_init() with the same ID can wait for the > shutdown to complete if necessary. > > The one change that is needed, in my opinion, is to clarify that > once > shutdown() has been called (i.e. the atomic action above has > occured) > on > an ORB instance, subsequent calls to all operations (or at least > run(), > shutdown(), work_pending(), and perform_work()) on that ORB instance > will raise BAD_INV_ORDER. As I mentioned in an earlier message, this doesn't work. When ORB_init is called without wait, it may well need a callback to run or perform_work to complete its task. But there is no obvious way for the caller to know whether this is true. I think we need to work out some code samples for how these calls should be used. Let me start with a simple one: // //Scenario 1 - single threaded orb, using run() // orb = ORB_init(...); ... orb->run(); //some servant method orb->shutdown(false); ... return; //run() returns // is the following required or allowed? orb->shutdown(true); // process rundown In the above, the 2nd call to shutdown should be unnecessary. Perhaps it should be illegal as well, but I am not sure about that. But lets look at the same thing not using run(): // //Scenario 2 - single threaded orb, using perform_work() // orb = ORB_init(...); ... for(running=true;running) { if(orb->work_pending()) orb->perform_work(); //some servant method running=false; orb->shutdown(false); ... return; else // do other stuff } // what to do here??? perhaps: orb->shutdown(true); // or maybe: while(orb->work_pending()) orb->perform_work(); // process rundown In scenario 2, use of the orb appears to be required after calling shutdown. I suppose it could work for awhile and then start throwing BAD_INV_ORDER. But if so, I hope that I don't have to use the occurrence of that exception as the "normal" exit from my shutdown processing. We need some multithreading examples too, but I haven't got time to write them now. I will try to do some when I get a chance. Return-Path: Date: Mon, 06 Jul 1998 09:31:15 -0400 From: Paul H Kyzivat Organization: NobleNet To: Jonathan Biggar CC: "Daniel R. Frantz" , port-rtf@omg.org Subject: Re: port-rtf Issue 735 proposal References: <00b501bda5de$4ce54ae0$3fc5bdce@idler.beasys.com> <359C0A98.FF02344B@noblenet.com> <359C5F43.7DA1ECCA@floorboard.com> Jonathan Biggar wrote: > > Actually, it should also be adequate if another thread is currently > blocked in ORB::run(), because that thread will only > unblock when the shutdown is complete. > > Jon As currently specified, any thread that calls run() is blocked till shutdown, but only the "main" thread is specified to do anything. Suppose some thread is blocked in run(), but it isn't the "main" thread? Then it may still be necessary for the "main" thread to call work_pending and perform_work, or else call run() itself. I put "main" in quotes because, as far as I know, the spec has no formal definition of what this means. My impression is that this is intentionally vague in order to accomodate differences in how platforms and ORBs are implemented. This may impose limitations in how portable code can be.