Issue 464: DII operations "get_response and get_next_response (orb_revision) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: Both operations permit the flag CORBA::RESP_NO_WAIT to be set. How is is invoker being informed that there is no response available? Incorrect to use exception. Resolution: resolved, closed issue Revised Text: The CORBA 2.2 revision changed the mapping for some DII operations and invalidated the C mapping for deferred synchronous DII. It may have done the same for other languages that followed the C mapping rather than the C++ mapping. This is both a language mapping issue and a Core issue because of the well-known mess in the PIDL for Request. Since the text for the C mapping is in the DII chapter (that is, Core), until that mess is cleaned up, it appears that orb_revision is the place to deal with the faulty C mapping. The problem is that the original (pre-2.2) PIDL for CORBA::Request had the operation Status get_response( in Flags invoke_flags); If the RESP_NO_WAIT flag is set, return is immediate, even if the response is not complete. Since "Status" was allowed to be mapped as a "long" (in CORBA 2.1 and before), the return value could be used to determine whether the response was ready by those implementations that cared. With CORBA 2.2, "Status" was replaced by "void", making it impossible to determine whether the response completed. Exactly the same situation is true for the mapping of operation get_next_response, for which no PIDL was ever given, only very disparate language mappings. The C++ mapping didn't use the Status approach. Its mapping added (among others) operations CORBA::Request::poll_response and CORBA::ORB::poll_next_response and redefined Request::get_response. The same was true for Smalltalk. We propose a similar approach to repair the C mapping. This does nothing to move the C, C++, and Smalltalk mappings out of the chapter, as they should be, but it at least makes the C mapping valid. Adding "poll_response" to the Request pseudo-object doesn't heal the disconnect between the PIDL and the language mappings -- obviously more needs to be done to get to a cleaner spec -- but at least a valid C language mapping would be restored. Revised Text: All references are to draft CORBA 2.3 (15-Nov-98). 1. Section 7.2 Request Operations, change the get_response operation and add the poll_response operation to the IDL at the end: void get_response () raises (WrongTransaction); boolean poll_response(); 2. Before 7.3.3, insert a section and renumber the following: 7.3.x poll_response /* C */ CORBA_boolean CORBA_Request_poll_response ( CORBA_Request, CORBA_Environment *); poll_response determines whether the request has completed. A TRUE return indicates that it has; FALSE indicates it has not. Return is immediate, whether the response has completed or not. Values in the request are not changed. 3. Change the current 7.3.3 "get_response" to the following, except leave the last paragraph as is. //PIDL void get_response () raises (WrongTransaction); get_response returns the result of a request. | If get_response is called before the request has | completed, it blocks until the request has | completed. Upon return, the out parameters and return values defined in the Request are set appropriately and they may be treated as if the Request invoke operation had been used to perform the request. 4. In the current 7.3.4 "get_next_response" a. Change the C mapping code to the following: /* C */ CORBA_boolean CORBA_poll_next_response ( CORBA_Environment *); void CORBA_get_next_response ( CORBA_Request *req, CORBA_Environment *env ); b. After the Smalltalk mapping, add the following paragraph. poll_next_response determines whether any request has completed. A TRUE return indicates that it has; FALSE indicates it has not. Return is immediate, whether any response has completed or not. c. Remove the two paragraphs beginning with: "If the RESP_NO_WAIT flag..." "The following response flag is defined ..." Actions taken: December 18, 1996: received issue March 5, 1999: moved from c-rev-wg to orb_revisiojn Discussion: End of Annotations:===== From: "Daniel R. Frantz" To: Subject: Issue 464. orb_revision, currently in c-rev-wg. get_response & get_next_response Date: Thu, 4 Mar 1999 17:49:17 -0500 X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 The CORBA 2.2 revision changed the mapping for some DII operations and invalidated the C mapping for deferred synchronous DII. It may have done the same for other languages that followed the C mapping rather than the C++ mapping. This is both a language mapping issue and a Core issue because of the well-known mess in the PIDL for Request. Since the text for the C mapping is in the DII chapter (that is, Core), until that mess is cleaned up, it appears that orb_revision is the place to deal with the faulty C mapping. The problem is that the original (pre-2.2) PIDL for CORBA::Request had the operation Status get_response( in Flags invoke_flags); If the RESP_NO_WAIT flag is set, return is immediate, even if the response is not complete. Since "Status" was allowed to be mapped as a "long" (in CORBA 2.1 and before), the return value could be used to determine whether the response was ready by those implementations that cared. With CORBA 2.2, "Status" was replaced by "void", making it impossible to determine whether the response completed. Exactly the same situation is true for the mapping of operation get_next_response, for which no PIDL was ever given, only very disparate language mappings. The C++ mapping didn't use the Status approach. Its mapping added (among others) operations CORBA::Request::poll_response and CORBA::ORB::poll_next_response and redefined Request::get_response. The same was true for Smalltalk. We propose a similar approach to repair the C mapping. This does nothing to move the C, C++, and Smalltalk mappings out of the chapter, as they should be, but it at least makes the C mapping valid. Adding "poll_response" to the Request pseudo-object doesn't heal the disconnect between the PIDL and the language mappings -- obviously more needs to be done to get to a cleaner spec -- but at least a valid C language mapping would be restored. All references are to draft CORBA 2.3 (15-Nov-98). 1. Section 7.2 Request Operations, change the get_response operation and add the poll_response operation to the IDL at the end: void get_response () raises (WrongTransaction); boolean poll_response(); 2. Before 7.3.3, insert a section and renumber the following: 7.3.x poll_response /* C */ CORBA_boolean CORBA_Request_poll_response ( CORBA_Request, CORBA_Environment *); poll_response determines whether the request has completed. A TRUE return indicates that it has; FALSE indicates it has not. Return is immediate, whether the response has completed or not. Values in the request are not changed. 3. Change the current 7.3.3 "get_response" to the following, except leave the last paragraph as is. //PIDL void get_response () raises (WrongTransaction); get_response returns the result of a request. The results of calling get_response before the request has completed (determined by a TRUE response to poll_response) is undefined. Upon return, the out parameters and return values defined in the Request are set appropriately and they may be treated as if the Request invoke operation had been used to perform the request. 4. In the current 7.3.4 "get_next_response" a. Change the C mapping code to the following: /* C */ CORBA_boolean CORBA_poll_next_response ( CORBA_Environment *); void CORBA_get_next_response ( CORBA_Request *req, CORBA_Environment *env ); b. After the Smalltalk mapping, add the following paragraph. poll_next_response determines whether any request has completed. A TRUE return indicates that it has; FALSE indicates it has not. Return is immediate, whether any response has completed or not. c. Remove the two paragraphs beginning with: "If the RESP_NO_WAIT flag..." "The following response flag is defined ..." Sender: jis@fpk.hp.com Date: Thu, 04 Mar 1999 18:43:04 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL To: juergen@omg.org CC: "Daniel R. Frantz" , orb_revision@omg.org Subject: Re: Issue 464. orb_revision, currently in c-rev-wg. get_response & get_next_response References: <003701be6691$3c8df560$3fc5bdce@idler.beasys.com> Juergen, Please move Issue 464 from wherever it is to orb_revision. We will propose Dan's suggested text as resolution in the next vote. 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: Fri, 12 Mar 1999 00:55:55 -0500 From: Bob Kukura Organization: IONA Technologies X-Accept-Language: en To: Jishnu Mukerji CC: Jeff Mischkinsky , Tom Rutt , Jonathan Biggar , Stephen McNamara , Randy Fox , Bill Janssen , Michi Henning , Juan Jose Hierro Sureda , Paul Kyzivat , Ken Cavanaugh , Edward Cobb , orb_revision@omg.org Subject: Re: Core RTF 2.4 Vote 6 References: <36E059B0.85497720@fpk.hp.com> IONA votes as follows: YES on 306, 380, 551, 565, 583, 584, 737, 751, 991, 1802, 2214, 2235, 2311, 2316, 2323, 2334, 2491, 2492, 2508, 2515 NO on 464 - The proposal says calling get_response before the request has completed is undefined. It should be defined to block until the response is available. Otherwise applications that want to block until a response is recieved are forced to loop calling poll_response until it returns TRUE before calling get_response. Even if you don't care about C, be aware that this is going to change the behaviour of the C++ mapping because the C++ mapping specification does not separately describe the semantics of get_response. NO on 1665 - The proposal does not reflect the current consensus. Our strongest objection to the current proposal is that calling shutdown(FALSE) should be sufficient, at least when the main thread is already in the middle of a call to run. Also, having shutdown(TRUE) implicitly call run can only portably be expected to have any effect when called in the main thread, since run only performs work when called in the main thread. What seems to be lost on the RTF is the POA submitters' intention that SINGLE_THREAD_MODEL POAs only dispatch operations in the main thread because of the existance on several platforms of library code that can only safely be run in the main thread (i.e. libraries that assume errno is static data). 2 on 2511 I urge everyone that voted YES on 464 and 1665 to reconsider your votes. I don't think the problem I discovered with 464 had been previously discussed, and many people voted YES on 1665 before the current email discussion. -Bob Date: Fri, 12 Mar 1999 16:26:03 +1000 (EST) From: Michi Henning To: Bob Kukura cc: Jishnu Mukerji , Jeff Mischkinsky , Tom Rutt , Jonathan Biggar , Stephen McNamara , Randy Fox , Bill Janssen , Juan Jose Hierro Sureda , Paul Kyzivat , Ken Cavanaugh , Edward Cobb , orb_revision@omg.org Subject: Re: Core RTF 2.4 Vote 6 Organization: Triodia Technologies On Fri, 12 Mar 1999, Bob Kukura wrote: > NO on 464 - The proposal says calling get_response before the request > has completed is undefined. It should be defined to block until the > response is available. Otherwise applications that want to block until > a response is recieved are forced to loop calling poll_response until it > returns TRUE before calling get_response. Looks like you are right :-( > I urge everyone that voted YES on 464 and 1665 to reconsider your > votes. I don't think the problem I discovered with 464 had been > previously discussed, and many people voted YES on 1665 before the > current email discussion. I already voted no on 1665. I agree with your analysis -- to my shame, I have to admit that I missed this problem when I read through the issue resolutions. So, for the moment, DSTC's vote for 464 changes to no. However, as you say, I think a friendly amendment would be sufficient to fix the problem: Change the sentence that currently reads: The results of calling get_response before the request has completed (determined by a TRUE response to poll_response) is undefined. To read: If get_response is called before the request has completed, it blocks until the request has completed. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Sender: jon@floorboard.com Date: Fri, 12 Mar 1999 09:56:51 -0800 From: Jonathan Biggar X-Accept-Language: en To: Paul H Kyzivat CC: Bob Kukura , Jishnu Mukerji , Jeff Mischkinsky , Tom Rutt , Jonathan Biggar , Stephen McNamara , Randy Fox , Bill Janssen , Michi Henning , Juan Jose Hierro Sureda , Ken Cavanaugh , Edward Cobb , orb_revision@omg.org Subject: Re: What was SINGLE_THREAD_MODEL intended to mean References: <36E059B0.85497720@fpk.hp.com> <36E8AC6B.D62F21BB@iona.com> <36E914BA.7585DE0A@noblenet.com> Paul H Kyzivat wrote: > While I have had the feeling (based on comments here and there) that > IONA believed this to be the meaning of SINGLE_THREAD_MODEL, it > seems to > have been missed by several non-submitters. If this was the > intention of > the submitters, then I think it failed to make it into the normative > text. Paul, I have to agree with IONA on this one, at least partially. There are threaded environments, where calling single threaded library code requires the use of the main thread to function properly. In these environments, the POA specification is pretty clear that the ORB implementation can require the application to call ORB::run() from the main thread, so that it can use the main thread to dispatch requests on SINGLE_THREAD_MODE POAs. So, any resolution to 1665, among others, needs to take this fact into account. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org