Issue 614: Threading and shutdown interfaces (port-rtf) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: The ORB interface for shutdown is incomplete and underspecified. work_pending and perform_work as specified are inadequate. See suggested changes in communicating archive file. Resolution: issue closed, no action Revised Text: Actions taken: June 20, 1997: received issue July 30, 1998: closed issue Discussion: End of Annotations:===== 2.0 ORB and the POA 2.1 Threading and shutdown interfaces The ORB interface for shutdown is incomplete and underspecified. The work_pending and perform_work as specified are inadequate and insufficiently clear. We also believe there is the need for a way for the user thread to block, waiting for work to be performed. The following changes are suggested: module CORBA { interface ORB { ... enum {holding, discarding, inactive } shutdown_state; exception inactive {} ; boolean running(); boolean work_pending(); void wait_for_work(); boolean perform_work_item(); boolean perform_work(); void run(); void shutdown( in shutdown_state exit_state, in boolean etherialize, in boolean wait_for_complete ); }; } 2.1.1 shutdown_state This indicates the state the POA Manager should be in as each POA is terminated. 2.1.2 running Indicates whether a shutdown() has been invoked, and whether current instances of run() will be exiting. 2.1.3 work_pending Indicates whether there is any work to be done, or whether a shutdown() has been invoked. If called after a shutdown() with exit_state == inactive, throws inactive. If called after shutdown with other exit_state, re-activates all POA managers. 2.1.4 wait_for_work Blocks until there is work_pending(). If called after a shutdown() with exit_state == inactive, throws inactive. If called after shutdown with other exit_state, re-activates all POA managers. 2.1.5 perform_work_item If there is any work to be done, executes at most a single upcall, and any other background work necessary. Boolean return says whether an upcall was made. If called after a shutdown() with exit_state == inactive, throws inactive. If called after shutdown with other exit_state, re-activates all POA managers. 2.1.6 perform_work If there is any work to be done, execute an implementation defined amount of it. Return TRUE if an upcall was made. If called after a shutdown() with exit_state == inactive, throws inactive. If called after shutdown with other exit_state, re-activates all POA managers. 2.1.7 run Continuously perform work until a shutdown() is called. If called after a shutdown() with exit_state == inactive, throws inactive. If called after shutdown with other exit_state, re-activates all POA managers. 2.1.8 shutdown Flag ORB shutdown for callers of the ORB run, running, work_pending, wait_for_work and perform_*work calls. Call all the POA managers, setting their state as indicated by "exit_state", and call deactivate with the other given arguments. If "exit_state" was either "holding" or "discarding", the managers may be restarted with subsequent calls to "run", "work_pending" or "wait_for_work". If "exit_state" was "inactive", subsequent calls to other operations will raise the "inactive" exception; otherwise such calls will re-activate the ORB. The provision of wait_for_work() and perform_work_item() allow the creation of user dispatch loops that perform wrapper work per-request, e.g., /* makes user deal with cancellation of unnecessary preop because some other thread got to the work item first. */ while( orb->running() ) { orb->wait_for_work(); user->preop(); if( orb->perform_work_item() ) user->postop() else user->cancelpreop() } It might be better to have flavors more clearly targeted for single-item dispatches: while( orb->running() ) { orb->wait_for_work_item(); if( orb->work_item_pending() ) { user->preop(); orb->perform_work_item(); user->postop(); } } wait_for_work_item performs background tasks, and returns on shutdown or presence of a pending upcall. work_item_pending checks for shutdown, performs background work, and binds a pending upcall to the current thread. perform_work_item processes the currently bound request, throwing some exception if nothing is bound. Another alternative is to make the work item handling explicit: native interface ORB_work_item { perform(); // destroys too } interface ORB { ... boolean work_item_pending( out ORB_work_item item ); } which would leave the user loop as: while( orb->running() ) { orb->wait_for_work(); if( orb->work_item_pending( &req ) ) { user->preop(); req->perform(); user->postop(); } } eturn-Path: From: "Daniel R. Frantz" To: Subject: Suggestions for issues 614, 648, 676, 744, 958, 964, 1314: no action Date: Mon, 29 Jun 1998 17:10:20 -0400 X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 I suggest we close the following issues with no action. Some enhancement issues were discussed and said to be impractical. Some met with opposition and will clearly never be accepted. Some answers are my own replies for enhancement requests that seem impractical. I think this shoots down a suggestion from almost everybody who's made more than one. I apologize if I've missed anybody. :-) Let me know if you disagree. We can take an email vote next week. Dan ======================================================== Issue 614: Threading and shutdown interfaces Nature: Enhancement Summary: The ORB interface for shutdown is incomplete and underspecified. work_pending and perform_work as specified are inadequate. See suggested changes in communicating archive file. Resolution: Closed with no action. It's not clear that the enhancements are useful. Issue 648: Server request and oneway operations Nature: Enhancement Summary: Given it's optional to call set_result operation of CORBA::ServerRequest, an ORB can't determine whether operation supported is oneway or not. Resolution: Closed with no action. The information is available in GIOP. Return-Path: Date: Tue, 30 Jun 1998 07:22:12 +0100 From: jhierro@jam.tid.es (Juan Jose Hierro Sureda) To: port-rtf@omg.org Subject: Re: Suggestions for issues 614, 648, 676, 744, 958, 964, 1314: no action X-Sun-Charset: US-ASCII > > I suggest we close the following issues with no action. > > Some enhancement issues were discussed and said to be > impractical. Some met with opposition and will clearly never be > accepted. Some answers are my own replies for enhancement > requests that seem impractical. I think this shoots down a > suggestion from almost everybody who's made more than one. I > apologize if I've missed anybody. :-) > > Let me know if you disagree. We can take an email vote next week. > > Dan I vote yes to the proposed resolutions and also agree with Jeff's sugestion regarding inclusion of the create_policy proposal in this RTF. -- Juanjo > > Issue 614: Threading and shutdown interfaces > Nature: Enhancement > Summary: The ORB interface for shutdown is incomplete and > underspecified. work_pending and perform_work as > specified are inadequate. See suggested changes > in communicating archive file. > Resolution: Closed with no action. It's not clear that the > enhancements are useful. > > Issue 648: Server request and oneway operations > Nature: Enhancement > Summary: Given it's optional to call set_result operation of > CORBA::ServerRequest, an ORB can't determine whether > operation supported is oneway or not. > Resolution: Closed with no action. The information is available > in GIOP. > > Issue 676: Use of root POA to implement root POA and POAMAnager > impossible > Nature: Error > Summary: It's impossible to use root POA to implement the root > POA and its POAManager, due to a deadlock because > POAManager starts in the HOLDING state. > Resolution: Closed with no action. The POA and POAManager are > implemented by the ORB so they must be special-cased > already. > > Issue 744: get_servant_manager and set_servant_manager > Nature: Revision > Summary: get_servant_manager and set_servant_manager > operations should not require the USE_SERVANT_MANAGER > policy to work. > Resolution: Closed with no action. The change would be > incompatible with the current specification. A > proposal for different entity on which to hang the > seemingly requested feature might be in order, such > as Issue 1162. > > Issue 958: Separator character for POAs should be specified > Nature: Enhancement > Summary: The Portability submission should specify a separator > character for POAs that may not be used in a POA name. > We propose that "/" be the separator character in POA > name, and that a "/" is not valid if used in a POA > name. This provides for vendors to provide a more > compact on-the-wire encoding, rather than use > sequence, and also is a convenience for the user if we > allow compound POA names to be used anywhere an > adapter_name is currently used in the POA APIs. > Resolution: Close with no action. On-the-wire representation of > POA name is implementer-defined. Providing a "compound > POA" name is not a feature that is universally > acclaimed. > > Issue 964: No POA hook for future Policies > Nature: Enhancement > Summary: The POA spec currently provides no hook for adding > future POA Policies. Several submission currently in > the works will be adding new policies to the POA. We > propose a generic create_policy() method which can be > used to create any Policy. We are open for discussion > on the signature, but a current thought is something > like this: Policy create_policy(PolicyType policyType, > Any policyValue); > Resolution: Closed with no action. The joint messaging RFP > submission had already included the ORB::create_policy > operation as part of the submission. > > Issue 1314: Access to the Active Object Map > Nature: Enhancement > Summary: How about adding visibility to the Active Object Map. > This would be beneficial to a factory-type server > application that created and activated Servants and > also periodically reported status on what it is in its > AOM. Changes to the spec would look something like: > module PortableServer { > typedef sequenceObjectSequence; > interface POA { ObjectSequence > get_active_objects(); > }; > }; > Resolution: Closed with no action. It is not possible to generate > such a list given the information known to the POA > because an ID and servant (the information the AOM) > do not uniquely specify an object reference. > > Return-Path: Date: Tue, 30 Jun 1998 19:01:02 -0400 From: Jonathan Biggar Organization: Floorboard Software To: "Daniel R. Frantz" CC: port-rtf@omg.org Subject: Re: Suggestions for issues 614, 648, 676, 744, 958, 964, > 1314: no action References: <005201bda3a2$53f81a80$3fc5bdce@idler.beasys.com> My comments on each one of these are included inline below: Daniel R. Frantz wrote: > I suggest we close the following issues with no action. > > Some enhancement issues were discussed and said to be > impractical. Some met with opposition and will clearly never be > accepted. Some answers are my own replies for enhancement > requests that seem impractical. I think this shoots down a > suggestion from almost everybody who's made more than one. I > apologize if I've missed anybody. :-) > > Let me know if you disagree. We can take an email vote next week. > > Dan > ======================================================== > > Issue 614: Threading and shutdown interfaces > Nature: Enhancement > Summary: The ORB interface for shutdown is incomplete and > underspecified. work_pending and perform_work as > specified are inadequate. See suggested changes > in communicating archive file. > Resolution: Closed with no action. It's not clear that the > enhancements are useful. I would argue that these are useful, and reasonably thought out to make it easier to integrate the ORB event processing loop with other event loops, like those from GUI libraries. The problem with work_pending() and such right now is that there isn't enough information to make an event loop that polls both for ORB events and GUI events without doing a busy poll on one or the other. Whether the proposed changes are exactly the right ones or not, I don't know yet, but I'd prefer that this one not be closed.