Issue 646: Blocking semantics of get_next_response not well specified (cxx_revision) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: The semantics of get_next_response sec 4.3.4 are not well-defined with respect to blocking behavior. There is no explicit description of the behavior of the C++ routines Resolution: resolved, issue closed Revised Text: Replace the 5th bullet point on page 23-118 of ptc/99-03-04 with: The get_response operation does not take a flag argument. If invoked before the request has completed, get_response blocks until the request completes; if invoked after the request has completed, get_response returns immediately. The poll_response operation returns immediately. A true return value indicates that the request has completed. A false return value indicates that the reply for the request is still outstanding. Actions taken: July 31, 1997: received issue June 13, 2000: closed issue Discussion: End of Annotations:===== Return-Path: Sender: "Jeff Mischkinsky" Date: Thu, 31 Jul 1997 15:55:31 -0700 From: Jeff Mischkinsky Organization: Visigenic Software To: cxx_revision@omg.org, juergen@omg.org CC: obj-prods@visigenic.com Subject: Blocking semantics of get_next_response not well specified C++ Mapping Issue ----------------- The semantics of get_next_response sec 4.3.4 are not well-defined with respect to blocking behavior. The semantics of get_next_response are defined clearly in the C description of the PIDL. In C, flags are defined and passed in which control the blocking/non-blocking behavior. In C++ the routine was split into 2 methods: poll_next_response() get_next_response() However, there is no explicit description of the behavior of the C++ routines. After careful consideration, we (Visigenic) decided that the only interpretation that makes sense, considering the decision in C++ to create 2 separate routines and not use a flag is as follows: The polling version exhibits non-blocking behavior, i.e. it returns immediately if there is no response currently waiting to be delivered. The non-polling version, get_next_response() will block (if there is no response currently waiting to be delivered) until a response becomes available. Unless there is strong objection to this being the correct interpretation, this is the behavior that our 3.0 products (currently in beta) will implement. Note also, that the smalltalk binding is in a similar bind, although there is some language in later sections that implies that this should also be the interpretation for Smalltalk. (see section 21.5) Please add this as an issue to be clarified in the next round of revisions. thanks, jeff -- Jeff Mischkinsky email: jeffm@visigenic.com Senior Software Architect voice: +1(415)312-5158 Visigenic Software, Inc. fax: +1(415)286-2475 951 Mariner's Island Blvd. Suite 460 web: http://www.visigenic.com San Mateo, CA 94404 Return-Path: X-Sender: dejong@pop-e5.ch.apollo.hp.com Date: Fri, 01 Aug 1997 09:28:37 -0400 To: Jeff Mischkinsky , cxx_revision@omg.org, juergen@omg.org From: Peter de Jong Subject: Re: Blocking semantics of get_next_response not well specified Cc: obj-prods@visigenic.com Jeff, At 03:55 PM 7/31/97 -0700, Jeff Mischkinsky wrote: >C++ Mapping Issue >----------------- >The semantics of get_next_response sec 4.3.4 are not well-defined with >respect to blocking behavior. > >The semantics of get_next_response are defined clearly in the C >description of the PIDL. In C, flags are defined and passed in which >control the blocking/non-blocking behavior. > >In C++ the routine was split into 2 methods: > poll_next_response() > get_next_response() >However, there is no explicit description of the behavior of the C++ >routines. > >After careful consideration, we (Visigenic) decided that the only >interpretation that makes sense, considering the decision in C++ to >create 2 separate routines and not use a flag is as follows: > > The polling version exhibits non-blocking behavior, i.e. it returns > immediately if there is no response currently waiting to be delivered. > > The non-polling version, get_next_response() will block (if there is > no response currently waiting to be delivered) until a response > becomes available. > >Unless there is strong objection to this being the correct >interpretation, this is the behavior that our 3.0 products (currently in >beta) will implement. In the java mapping, and probably the C++ mapping, there is still an ambiguity in poll_next_response when it returns with a null boolean. There is no way to distinguish between no pending response delivered, or all responses have been delivered. This might be hard for a user to keep track of since multiple send_multiple_requests_deferred can be invoked, dynamically adding to the list of pending responses. get_next_response can return null when all responses have been delivered. Peter =================================================================== Peter de Jong Internet Technology Lab dejong@apollo.hp.com Hewlett-Packard Company Tel: 508/436-5372 300 Apollo Drive Fax: 508/436-5176 Chelmsford, MA. 01824 ====================================================================