Issue 3052: CORBA::PollableSet::poll and CORBA::Poller::is have same semantics (messaging-rtf) Source: UBS (Mr. Hans Kneubuehl, hans.kneubuehl(at)ubs.com) Nature: Uncategorized Issue Severity: Summary: 1. The operations CORBA::PollableSet::poll and CORBA::Poller::is_ready both have the same semantics: verify if a reply message is available and can be retrieved. The first one works on a set of pollers, the second one on a single poller. -> The naming of these operations should therefore be consistent. -> possible correction: define (additionally) a CORBA::PollableSet::is_ready Operation. Mark the existing one as obsolete. Resolution: resolved Revised Text: Actions taken: November 19, 1999: received issue January 9, 2001: closed issue Discussion: he following changes are referring to document ptc/00-02-05. p. 1-41, change "In this example, after the PollableSet::poll indicates that a particular Poller has finished, the code makes the call on the type-specific poller in a non-blocking manner and doesn't bother checking for completion in the return value. Checking isn't necessary when only a single client is using the Poller, but it is the safe practice if multiple clients are waiting." to read "In this example, after the PollableSet::get_ready_pollable indicates that a particular Poller has finished, the code makes the call on the type-specific poller in a non-blocking manner and doesn't bother checking for completion in the return value. Checking isn't necessary when only a single client is using the Poller, but it is the safe practice if multiple clients are waiting." p. 1-42, change while (poll_set->number_left() > 0) { // wait for a completion CORBA::Pollable_ptr pollable = poll_set->poll(max_timeout); // the returned Pollable is ready to return its reply to read while (poll_set->number_left() > 0) { // wait for a completion CORBA::Pollable_ptr pollable = poll_set->get_ready_pollable(max_timeout); // the returned Pollable is ready to return its reply p. 1-99, speaks about PollableSet, but no change needed The following changes are referring to document ptc/99-12-07 p. 7-13 - 7-14, change interface PollableSet { exception NoPossiblePollable { }; exception UnknownPollable { }; DIIPollable create_dii_pollable(); void add_pollable( in Pollable potential ); Pollable poll( in unsigned long timeout ) raises( NoPossiblePollable ); void remove( in Pollable potential ) raises( UnknownPollable ); unsigned short number_left( ); }; to read interface PollableSet { exception NoPossiblePollable { }; exception UnknownPollable { }; DIIPollable create_dii_pollable(); void add_pollable( in Pollable potential ); Pollable get_ready_pollable( in unsigned long timeout ) raises( NoPossiblePollable ); void remove( in Pollable potential ) raises( UnknownPollable ); unsigned short number_left( ); }; p. 7-15, change "7.4.3 interface PollableSet The pollable set contains potential happenings for which a poll can be performed. The client adds potential happenings to the set and later polls the set to see if any have occurred. PollableSet is a locality constrained object." to read "7.4.3 interface PollableSet The pollable set contains potential happenings for which a poll can be performed. The client adds potential happenings to the set and later queries the set to see if any have occurred. PollableSet is a locality constrained object." p. 7-15 - 7-16, change "7.4.3.3 poll Pollable poll( in unsigned long timeout ) raises( NoPossiblePollable ); The poll operation asks the PollableSet if any of its potential happenings have occurred. The timeout parameter indicates for how many milliseconds this call should wait until the response becomes available. If this timeout expires before a reply is available, the operation raises the standard system exception CORBA::TIMEOUT. Any delegated invocations used by the implementation of this polling operation are subject to the single timeout parameter, which supersedes any ORB or thread-level timeout quality of service. Two specific values are of interest: * 0 - the call is a non-blocking poll which raises the standard system exception CORBA::NO_RESPONSE if the reply is not immediately available * 232-1 - the maximum value for unsigned long indicates no timeout should be used. The poll will not return until the reply is available. If the PollableSet contains no potential happenings, the NoPossiblePollable exception is raised. If an actual happening is returned, the PollableSet removes that happening from the set. For the typed Poller, removing the happening is necessary since its usefulness ends once the Poller completes. In the case of a DII happening, there may still be deferred requests outstanding; if this is the case, the client application must add the DIIPollable again to the PollableSet. When the poll operation blocks, the ORB has control of the thread and can process any work it has (such as receiving and dispatching requests through its Object Adapter). The poll operation can be used in an "event-style main loop" using ORB::work_pending and ORB::perform_work. If the ORB supports multiple threads, one thread may be blocking on a PollableSet while another is adding and removing potential happenings from the set. It is valid for the PollableSet to change dynamically while a poll is in progress. If another thread?s PollableSet::remove operation leaves the PollableSet empty, any blocked threads raise the NoPossiblePollable exception." to read "7.4.3.3 poll Pollable get_ready_pollable( in unsigned long timeout ) raises( NoPossiblePollable ); The get_ready_pollable operation asks the PollableSet if any of its potential happenings have occurred. The timeout parameter indicates for how many milliseconds this call should wait until the response becomes available. If this timeout expires before a reply is available, the operation raises the standard system exception CORBA::TIMEOUT. Any delegated invocations used by the implementation of this polling operation are subject to the single timeout parameter, which supersedes any ORB or thread-level timeout quality of service. Two specific values are of interest: * 0 - the call is a non-blocking query which raises the standard system exception CORBA::NO_RESPONSE if the reply is not immediately available * 232-1 - the maximum value for unsigned long indicates no timeout should be used. The query will not return until the reply is available. If the PollableSet contains no potential happenings, the NoPossiblePollable exception is raised. If an actual happening is returned, the PollableSet removes that happening from the set. For the typed Poller, removing the happening is necessary since its usefulness ends once the Poller completes. In the case of a DII happening, there may still be deferred requests outstanding; if this is the case, the client application must add the DIIPollable again to the PollableSet. When the get_ready_pollable operation blocks, the ORB has control of the thread and can process any work it has (such as receiving and dispatching requests through its Object Adapter). The get_ready_pollable operation can be used in an "event-style main loop" using ORB::work_pending and ORB::perform_work. If the ORB supports multiple threads, one thread may be blocking on a PollableSet while another is adding and removing potential happenings from the set. It is valid for the PollableSet to change dynamically while a query is in progress. If another thread?s PollableSet::remove operation leaves the PollableSet empty, any blocked threads raise the NoPossiblePollable exception." p. 7-16, change "7.4.3.5 number_left unsigned short number_left( ); The number_left operation returns the number of potential happenings in the pollable set. A returned value of zero means that there are no potential happenings in the set, in which case a poll on the set would raise the NoPossibleHappening exception." to read "7.4.3.5 number_left unsigned short number_left( ); The number_left operation returns the number of potential happenings in the pollable set. A returned value of zero means that there are no potential happenings in the set, in which case a query on the set would raise the NoPossibleHappening exception. End of Annotations:===== From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Fri, 19 Nov 1999 11:00:32 +0100 Message-Id: Subject: messaging issues: inconsistent specification MIME-Version: 1.0 TO: issues@omg.org, messaging-rtf@omg.org CC: sgw@adnovum.com Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Fri, 19 Nov 1999 11:00:32 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Fri, 19 Nov 1999 11:00:32 +0100" X-UIDL: #'Ie9P#hd9=b[d9a8Ld9 Hi I would like to raise the following issue with Messaging. (I'm aware that beauty-surgery-changes might nonecessary when only a single client is using the Poller, but it is the safe practice if multiple clients are waiting." p. 1-42, change while (poll_set->number_left() > 0) { // wait for a completion CORBA::Pollable_ptr pollable = poll_set->poll(max_timeout); // the returned Pollable is ready to return its reply to read while (poll_set->number_left() > 0) { // wait for a completion CORBA::Pollable_ptr pollable = poll_set->is_ready(max_timeout); // the returned Pollable is ready to return its reply p. 1-99, speaks about PollableSet, but no change needed The following changes are referring to document ptc/99-12-07 p. 7-13 - 7-14, change interface PollableSet { exception NoPossiblePollable { }; exception UnknownPollable { }; DIIPollable create_dii_pollable(); void add_pollable( in Pollable potential ); Pollable poll( in unsigned long timeout ) raises( NoPossiblePollable ); void remove( in Pollable potential ) raises( UnknownPollable ); unsigned short number_left( ); }; to read interface PollableSet { exception NoPossiblePollable { }; exception UnknownPollable { }; DIIPollable create_dii_pollable(); void add_pollable( in Pollable potential ); Pollable is_ready( in unsigned long timeout ) raises( NoPossiblePollable ); void remove( in Pollable potential ) raises( UnknownPollable ); unsigned short number_left( ); Pollable poll( // obsolete in unsigned long timeout ) raises( NoPossiblePollable ); }; p. 7-15, change "7.4.3 interface PollableSet The pollable set contains potential happenings for which a poll can be performed. The client adds potential happenings to the set and later polls the set to see if any have occurred. PollableSet is a locality constrained object." to read "7.4.3 interface PollableSet The pollable set contains potential happenings for which a poll can be performed. The client adds potential happenings to the set and later queries the set to see if any have occurred. PollableSet is a locality constrained object." p. 7-15 - 7-16, change "7.4.3.3 poll Pollable poll( in unsigned long timeout ) raises( NoPossiblePollable ); The poll operation asks the PollableSet if any of its potential happenings have occurred. The timeout parameter indicates for how many milliseconds this call should wait until the response becomes available. If this timeout expires before a reply is available, the operation raises the standard system exception CORBA::TIMEOUT. Any delegated invocations used by the implementation of this polling operation are subject to the single timeout parameter, which supersedes any ORB or thread-level timeout quality of service. Two specific values are of interest: 0 - the call is a non-blocking poll which raises the standard system exception CORBA::NO_RESPONSE if the reply is not immediately available 232-1 - the maximum value for unsigned long indicates no timeout should be used. The poll will not return until the reply is available. If the PollableSet contains no potential happenings, the NoPossiblePollable exception is raised. If an actual happening is returned, the PollableSet removes that happening from the set. For the typed Poller, removing the happening is necessary since its usefulness ends once the Poller completes. In the case of a DII happening, there may still be deferred requests outstanding; if this is the case, the client application must add the DIIPollable again to the PollableSet. When the poll operation blocks, the ORB has control of the thread and can process any work it has (such as receiving and dispatching requests through its Object Adapter). The poll operation can be used in an t be in the scope of an RTF, but I think it's still worth to give them some attention.) 1. The operations CORBA::PollableSet::poll and CORBA::Poller::is_ready both have the same semantics: verify if a reply message is available and can be retrievde using ORB::work_pending and ORB::perform_work. If the ORB supports multiple threads, one thread may be blocking on a PollableSet while another is adding and removing potential happenings from the set. It is valid for the PollableSet to change dynamically while a poll ithreads raise the NoPossiblePollable exception." to read "7.4.3.3 poll Pollable is_ready( in unsigned long timeout ) raises( NoPossiblePollable ); The is_ready operation asks the PollableSet if any of its potential happenings have occurred. The timeout parameter indicates for how many milliseconds this call should wait until the response becomes available. If this timeout expires before a reply is available, the operation raises the standard system exception CORBA::TIMEOUT. Any delegated invocations used by the implementation of this polling operation are subject to the single timeout parameter, which supersedes any ORB or thread-level timeout quality of service. Two specific values are of interest: 0 - the call is a non-blocking query which raises the standard system exception CORBA::NO_RESPONSE if the reply is not immediately available 232-1 - the maximum value for unsigned long indicates no timeout should be used. The query will not return until the reply is available. If the PollableSet contains no potential happenings, the NoPossiblePollable exception is raised. If an actual happening is returned, the PollableSet removes that happening from the set. For the typed Poller, removing the happening is necessary since its usefulness ends once the Poller completes. In the case of a DII happening, there may still be deferred requests outstanding; if this is the case, the client application must add the DIIPollable again to the PollableSet. When the is_ready operation blocks, the ORB has control of the thread and can process any work it has (such as receiving and dispatching requests through its Object Adapter). The is_ready operation can be used in an s in progress. If another thread. The first one works on a set of pollers, the second one on a single poller. -> The naming of these operations should therefore be consistent. -> possible correction: define (additionally) a CORBA::PollableSet::is_ready Operation. Mark the existing one as obsolete. From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Sat, 11 Mar 2000 02:51:56 +0100 Message-Id: Subject: 3052 (is_ready): straw man proposal MIME-Version: 1.0 TO: messaging-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Sat, 11 Mar 2000 02:51:56 +0100" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8binecessary when only a single client is using the Poller, but it is the safe practice if multiple clients are waiting." to read "In this example, after the PollableSet::is_ready indicates that a particular Poller has finished, the code makes the call on the type-specific poller in a non-blocking manner and doesnt by emerald.omg.org id VAA12636 Content-Type: text/plain; charset=ISO-8859-1 ;Creation-Date="Sat, 11 Mar 2000 02:51:56 +0100" X-UIDL: R[G!!adY!!O`B!!6>#!! I could imagine that the resolution to issue 3052 could be quite indisputable and would like to propose directly a votable resolution. > Issue 3052: CORBA::PollableSet::poll and CORBA::Poller::is have same semantics > > Summary: 1. The operations CORBA::PollableSet::poll and CORBA::Poller::is_ready > both have the same semantics: verify if a reply message is available and can be > retrievde using ORB::work_pending and ORB::perform_work. If the ORB supports multiple threads, one thread may be blocking on a PollableSet while another is adding and removing potential happenings from the set. It is valid for the PollableSet to change dynamically while a query ithreads raise the NoPossiblePollable exception. The poll operation has the same behavior as the is_ready operation. It is provided only for backward compatibility. New applications should not use this operation as future revisions will remove it." p. 7-16, change "7.4.3.5 number_left unsigned short number_left( ); The number_left operation returns the number of potential happenings in the pollable set. A returned value of zero means that there are no potential happenings in the set, in which case a poll on the set would raise the NoPossibleHappening exception." to read "7.4.3.5 number_left unsigned short number_left( ); The number_left operation returns the number of potential happenings in the pollable set. A returned value of zero means that there are no potential happenings in the set, in which case a query on the set would raise the NoPossibleHappening exception. " Rational: --------- The operation 'poll' on PollableSet leads to confusion because polling refers to receiving the actual reply in the other places of the document whereas PollableSet::poll refers only to find out which reply is ready to be received. There is already an equivalent operation for this on a single poller (see abstract valuetype pollable) that is called 'is_ready'. Therefore, for consistency and terminology reasons, the equivalent operations on pollers and poller sets should be named the same. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 s in progress. If another thread. The first one works on a set of pollers, the second one on a single > poller. -> The naming of these operations should therefore be consistent. -> > possible correction: define (additionally) a CORBA::PollableSet::is_ready > Operation. Mark the existing one as obsolete. Proposed Resolution: -------------------- The following changes are referring to document ptc/00-02-05. p. 1-41, change "In this example, after the PollableSet::poll indicates that a particular Poller has finished, the code makes the call on the type-specific poller in a non-blocking manner and doesn Sender: Chris.Smith@uab.ericsson.se Message-ID: <38CCE4CE.4CF85556@uab.ericsson.se> Date: Mon, 13 Mar 2000 13:53:34 +0100 From: Chris Smith X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: hans.kneubuehl@ubs.com CC: messaging-rtf@omg.org Subject: Re: 3052 (is_ready): straw man proposal References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: aJ?!!I8He95dF!!mAJe9 Thanks for the straw man on this issue Hans. I kind of agree with the intent of your proposal but disagree a little with some of the details. 1) If it is so important that the operation name for polling is the same on the Poller and PollableSet then I think you should change the name on the Poller, not the PollableSet. You now have an operation on PollableSet called is_ready(), and this seems bizarre. The PollableSet is not something that seems to be "ready". It would be better to change the is_ready() operation on Poller to be called poll(). 2) I think if we should add a new operation for the changed name in one of the interfaces, we should remove the old one, and not just mark it as obsolete. This specification is not part of a published CORBA spec yet, and so one could consider this work as an FTF really.... Chris hans.kneubuehl@ubs.com wrote: > > I could imagine that the resolution to issue 3052 could be quite > indisputable > and would like to propose directly a votable resolution. > > > Issue 3052: CORBA::PollableSet::poll and CORBA::Poller::is have > same semantics > > > > Summary: 1. The operations CORBA::PollableSet::poll and > CORBA::Poller::is_ready > > both have the same semantics: verify if a reply message is > available and can > be > > retrieved. The first one works on a set of pollers, the second one > on a single > > poller. -> The naming of these operations should therefore be > consistent. -> > > possible correction: define (additionally) a > CORBA::PollableSet::is_ready > > Operation. Mark the existing one as obsolete. > > Proposed Resolution: > -------------------- > The following changes are referring to document ptc/00-02-05. > > p. 1-41, change > > "In this example, after the PollableSet::poll indicates that a > particular > Poller has > finished, the code makes the call on the type-specific poller in a > non-blocking > manner > and doesn?the renecessary when only a single client is using the > Poller, but it is the safe practice if multiple clients are waiting." p. 1-42, change while (poll_set->number_left() > 0) { // wait for a completion CORBA::Pollable_ptr pollable = poll_set->poll(max_timeout); // the returned Pollable is ready to return its reply to read while (poll_set->number_left() > 0) { // wait for a completion CORBA::Pollable_ptr pollable = poll_set->get_ready_pollable(max_timeout); // the returned Pollable is ready to return its reply p. 1-99, speaks about PollableSet, but no change needed The following changes are referring to document ptc/99-12-07 p. 7-13 - 7-14, change interface PollableSet { exception NoPossiblePollable { }; exception UnknownPollable { }; DIIPollable create_dii_pollable(); void add_pollable( in Pollable potential ); Pollable poll( in unsigned long timeout ) raises( NoPossiblePollable ); void remove( in Pollable potential ) raises( UnknownPollable ); unsigned short number_left( ); }; to read interface PollableSet { exception NoPossiblePollable { }; exception UnknownPollable { }; DIIPollable create_dii_pollable(); void add_pollable( in Pollable potential ); Pollable get_ready_pollable( in unsigned long timeout ) raises( NoPossiblePollable ); void remove( in Pollable potential ) raises( UnknownPollable ); unsigned short number_left( ); }; p. 7-15, change "7.4.3 interface PollableSet The pollable set contains potential happenings for which a poll can be > performed. The client adds potential happenings to the set and later polls the set to > see if any have occurred. PollableSet is a locality constrained object." to read "7.4.3 interface PollableSet The pollable set contains potential happenings for which a poll can be > performed. The client adds potential happenings to the set and later queries the set > to see if any have occurred. PollableSet is a locality constrained object." p. 7-15 - 7-16, change "7.4.3.3 poll Pollable poll( in unsigned long timeout ) raises( NoPossiblePollable ); The poll operation asks the PollableSet if any of its potential > happenings have occurred. The timeout parameter indicates for how many milliseconds > this call should wait until the response becomes available. If this timeout > expires before a reply is available, the operation raises the standard system exception > CORBA::TIMEOUT. Any delegated invocations used by the implementation of this polling > operation are subject to the single timeout parameter, which supersedes any ORB or thread-level timeout quality of service. Two specific values are of interest: 0 - the call is a non-blocking poll which raises the standard > system exception CORBA::NO_RESPONSE if the reply is not immediately available 232-1 - the maximum value for unsigned long indicates no timeout > should be used. The poll will not return until the reply is available. If the PollableSet contains no potential happenings, the NoPossiblePollable exception is raised. If an actual happening is returned, the PollableSet removes that happening from the set. For the typed Poller, removing the happening is necessary since its usefulness ends once the Poller completes. In the case of a DII happening, there may still be deferred requests outstanding; if this is the case, the client application must add the DIIPollable again to the PollableSet. When the poll operation blocks, the ORB has control of the thread and > can process any work it has (such as receiving and dispatching requests through > its Object Adapter). The poll operation can be used in an turn value. Checking isnt bother checking for completion in the return > value. Checking isn?t > necessary when only a single client is using the Poller, but it is > the safe > practice if > multiple clients are waiting." > > to read > > "In this example, after the PollableSet::is_ready indicates that a > particular > Poller has > finished, the code makes the call on the type-specific poller in a > non-blocking > manner > and doesn?necessary when only a single client is using the Poller, > but it is the safe practice if multiple clients are waiting." to read "In this example, after the PollableSet::get_ready_pollable indicates > that a particular Poller has finished, the code makes the call on the > type-specific poller in a non-blocking manner and doesnt bother checking for completion in the return > value. Checking isn?t > necessary when only a single client is using the Poller, but it is > the safe > practice if > multiple clients are waiting." > > p. 1-42, change > > while (poll_set->number_left() > 0) { > // wait for a completion > CORBA::Pollable_ptr pollable = poll_set->poll(max_timeout); > // the returned Pollable is ready to return its reply > > to read > > while (poll_set->number_left() > 0) { > // wait for a completion > CORBA::Pollable_ptr pollable = poll_set->is_ready(max_timeout); > // the returned Pollable is ready to return its reply > > p. 1-99, speaks about PollableSet, but no change needed > > The following changes are referring to document ptc/99-12-07 > > p. 7-13 - 7-14, change > > interface PollableSet { > > exception NoPossiblePollable { }; > exception UnknownPollable { }; > > DIIPollable create_dii_pollable(); > > void add_pollable( > in Pollable potential > ); > > Pollable poll( > in unsigned long timeout > ) raises( NoPossiblePollable ); > > void remove( > in Pollable potential > ) raises( UnknownPollable ); > > unsigned short number_left( ); > }; > > to read > > interface PollableSet { > > exception NoPossiblePollable { }; > exception UnknownPollable { }; > > DIIPollable create_dii_pollable(); > > void add_pollable( > in Pollable potential > ); > > Pollable is_ready( > in unsigned long timeout > ) raises( NoPossiblePollable ); > > void remove( > in Pollable potential > ) raises( UnknownPollable ); > > unsigned short number_left( ); > > Pollable poll( // obsolete > in unsigned long timeout > ) raises( NoPossiblePollable ); > > }; > > p. 7-15, change > > "7.4.3 interface PollableSet > > The pollable set contains potential happenings for which a poll can > be > performed. The > client adds potential happenings to the set and later polls the set > to see if > any have > occurred. PollableSet is a locality constrained object." > > to read > > "7.4.3 interface PollableSet > > The pollable set contains potential happenings for which a poll can > be > performed. The > client adds potential happenings to the set and later queries the > set to see if > any have > occurred. PollableSet is a locality constrained object." > > p. 7-15 - 7-16, change > > "7.4.3.3 poll > > Pollable poll( > in unsigned long timeout > ) raises( NoPossiblePollable ); > > The poll operation asks the PollableSet if any of its potential > happenings have > occurred. The timeout parameter indicates for how many milliseconds > this call > should wait until the response becomes available. If this timeout > expires > before a reply > is available, the operation raises the standard system exception > CORBA::TIMEOUT. > Any delegated invocations used by the implementation of this polling > operation > are > subject to the single timeout parameter, which supersedes any ORB or > thread-level > timeout quality of service. Two specific values are of interest: > * 0 - the call is a non-blocking poll which raises the standard > system exception > CORBA::NO_RESPONSE if the reply is not immediately available > * 232-1 - the maximum value for unsigned long indicates no timeout > should be > used. The poll will not return until the reply is available. > > If the PollableSet contains no potential happenings, the > NoPossiblePollable > exception is raised. If an actual happening is returned, the > PollableSet > removes that > happening from the set. For the typed Poller, removing the happening > is > necessary > since its usefulness ends once the Poller completes. In the case of > a DII > happening, > there may still be deferred requests outstanding; if this is the > case, the > client > application must add the DIIPollable again to the PollableSet. > > When the poll operation blocks, the ORB has control of the thread > and can > process > any work it has (such as receiving and dispatching requests through > its Object > Adapter). The poll operation can be used in an ?event-style mani > using ORB::work_pending and ORB::perform_work. If the ORB supports multiple threads, one thread may be blocking on a PollableSet while another is adding and removing potential happenings from the set. It is valid for the PollableSet to change dynamically while a poll ithreads raise the NoPossiblePollable exception." to read "7.4.3.3 poll Pollable get_ready_pollable( in unsigned long timeout ) raises( NoPossiblePollable ); The get_ready_pollable operation asks the PollableSet if any of its potential happenings have occurred. The timeout parameter indicates for how many milliseconds this call should wait until the response becomes available. If this timeout expires before a reply is available, the operation raises the standard system exception CORBA::TIMEOUT. Any delegated invocations used by the implementation of this polling operation are subject to the single timeout parameter, which supersedes any ORB or thread-level timeout quality of service. Two specific values are of interest: 0 - the call is a non-blocking query which raises the standard system exception CORBA::NO_RESPONSE if the reply is not immediately available 232-1 - the maximum value for unsigned long indicates no timeout should be used. The query will not return until the reply is available. If the PollableSet contains no potential happenings, the NoPossiblePollable exception is raised. If an actual happening is returned, the PollableSet removes that happening from the set. For the typed Poller, removing the happening is necessary since its usefulness ends once the Poller completes. In the case of a DII happening, there may still be deferred requests outstanding; if this is the case, the client application must add the DIIPollable again to the PollableSet. When the get_ready_pollable operation blocks, the ORB has control of the thread and can process any work it has (such as receiving and dispatching requests through its Object Adapter). The get_ready_pollable operation can be used in an s in progress. If another thread > loop? using > ORB::work_pending and ORB::perform_work. > > If the ORB supports multiple threads, one thread may be blocking on > a > PollableSet > while another is adding and removing potential happenings from the > set. It is > valid for > the PollableSet to change dynamically while a poll is in > progress. If another > thread?threads raise the NoPossiblePollable exception." p. 7-16, change "7.4.3.5 number_left unsigned short number_left( ); The number_left operation returns the number of potential happenings > in the pollable set. A returned value of zero means that there are no potential > happenings in the set, in which case a poll on the set would raise the NoPossibleHappening > exception." to read "7.4.3.5 number_left unsigned short number_left( ); The number_left operation returns the number of potential happenings > in the pollable set. A returned value of zero means that there are no potential > happenings in the set, in which case a query on the set would raise the NoPossibleHappening > exception. " Rational: --------- The operation 'poll' on PollableSet leads to confusion because polling > refers to receiving the actual reply in the other places of the document > whereas PollableSet::poll refers only to find out which reply is ready to be > received. There is already a similar operation for this on a single poller (see > abstract valuetype pollable) that is called 'is_ready' which is a boolean query > operation. The operation on the pollable set corresponds to the 'get_next' query operations (also with side effect) that are usually found on iterators. Therefore the proposal to change it to 'get_ready_pollable'. The acceptance of this resolution would make it clear and consistent > that 'polling' (in the messaging submission) refers to receiving the actual > reply by the application whereas query operations have to something with the > readyness of pollers. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 s PollableSet::remove operation leaves the PollableSet empty, > any blocked > threads raise the NoPossiblePollable exception." > > to read > > "7.4.3.3 poll > > Pollable is_ready( > in unsigned long timeout > ) raises( NoPossiblePollable ); > > The is_ready operation asks the PollableSet if any of its potential > happenings > have > occurred. The timeout parameter indicates for how many milliseconds > this call > should wait until the response becomes available. If this timeout > expires > before a reply > is available, the operation raises the standard system exception > CORBA::TIMEOUT. > Any delegated invocations used by the implementation of this polling > operation > are > subject to the single timeout parameter, which supersedes any ORB or > thread-level > timeout quality of service. Two specific values are of interest: > * 0 - the call is a non-blocking query which raises the standard > system > exception > CORBA::NO_RESPONSE if the reply is not immediately available > * 232-1 - the maximum value for unsigned long indicates no timeout > should be > used. The query will not return until the reply is available. > > If the PollableSet contains no potential happenings, the > NoPossiblePollable > exception is raised. If an actual happening is returned, the > PollableSet > removes that > happening from the set. For the typed Poller, removing the happening > is > necessary > since its usefulness ends once the Poller completes. In the case of > a DII > happening, > there may still be deferred requests outstanding; if this is the > case, the > client > application must add the DIIPollable again to the PollableSet. > > When the is_ready operation blocks, the ORB has control of the > thread and can > process > any work it has (such as receiving and dispatching requests through > its Object > Adapter). The is_ready operation can be used in an ?event-style mainlopo using ORB::work_pending and ORB::perform_work. If the ORB supports multiple threads, one thread may be blocking on a PollableSet while another is adding and removing potential happenings from the set. It is valid for the PollableSet to change dynamically while a query is in progress. If another thread > loop? using > ORB::work_pending and ORB::perform_work. > > If the ORB supports multiple threads, one thread may be blocking on > a > PollableSet > while another is adding and removing potential happenings from the > set. It is > valid for > the PollableSet to change dynamically while a query is in > progress. If another > thread?s PollableSet::remove operation leaves the PollableSet empty, > any blocked > threads raise the NoPossiblePollable exception. > > The poll operation has the same behavior as the is_ready > operation. It is > provided only for backward compatibility. New applications should > not use this > operation as future revisions will remove it." > > p. 7-16, change > > "7.4.3.5 number_left > > unsigned short number_left( ); > > The number_left operation returns the number of potential happenings > in the > pollable > set. A returned value of zero means that there are no potential > happenings in > the set, > in which case a poll on the set would raise the NoPossibleHappening > exception." > > to read > > "7.4.3.5 number_left > > unsigned short number_left( ); > > The number_left operation returns the number of potential happenings > in the > pollable > set. A returned value of zero means that there are no potential > happenings in > the set, > in which case a query on the set would raise the NoPossibleHappening > exception. > " > > Rational: > --------- > > The operation 'poll' on PollableSet leads to confusion because > polling refers > to receiving the actual reply in the other places of the document > whereas > PollableSet::poll refers only to find out which reply is ready to be > received. > There is already an equivalent operation for this on a single poller > (see > abstract valuetype pollable) that is called 'is_ready'. Therefore, > for > consistency and terminology reasons, the equivalent operations on > pollers and > poller sets should be named the same. > > Regards > Hans > -- > Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland > phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Tue, 14 Mar 2000 10:08:22 +0100 Message-Id: Subject: Re: 3052 (is_ready): straw man proposal MIME-Version: 1.0 TO: uabcsru@uab.ericsson.se CC: messaging-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Tue, 14 Mar 2000 10:08:22 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Tue, 14 Mar 2000 10:08:22 +0100" X-UIDL: SW*!!FD?!!U -----Original Message----- > From: uabcsru [mailto:uabcsru@uab.ericsson.se] > Sent: Monday, March 13, 2000 1:54 PM > 1) If it is so important that the operation name > for polling is the same on the Poller and PollableSet > then I think you should change the name on the Poller, not > the PollableSet. You now have an operation on PollableSet > called is_ready(), and this seems bizarre. The PollableSet > is not something that seems to be "ready". It would be better > to change the is_ready() operation on Poller to be called > poll(). You are right, PollableSet::is_ready is wrong. is_ready should be the name of a boolean query operation. This is fine in case of the poller. There it is really a pure query operation without any side effects. What about PollableSet::get_ready_pollable? For iterators it's quite common that they have a "query" operation called something like 'get_next' with side effects. I think the problem with PollableSet::poll is that 'poll' is really used throughout the document in the meaning of 'retrieving a reply'. The operations on PollableSet and Pollable are both about finding out whether a reply is ready to be received, but they are not really the same, they are just similar (thanks for pointing this out). Therefore, I was wrong by requiring that a consistent naming gives both operations the same name. I will revise my proposal accordingly. > 2) I think if we should add a new operation for the changed > name in one of the interfaces, we should remove the old one, and > not just mark it as obsolete. This specification is not part > of a published CORBA spec yet, and so one could consider this > work as an FTF really.... This is fine with me. I will remove it from the proposal. Thanks and regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Wed, 15 Mar 2000 08:17:07 +0100 Message-Id: Subject: 3052 (is_ready): updated straw man proposal MIME-Version: 1.0 TO: uabcsru@uab.ericsson.se CC: messaging-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Wed, 15 Mar 2000 08:17:07 +0100" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id FAA29195 Content-Type: text/plain; charset=ISO-8859-1 ;Creation-Date="Wed, 15 Mar 2000 08:17:07 +0100" X-UIDL: W(od9(Y9e9[TO!!71Le9 Below you find the updated resolution proposal to issue 3052. The proposed name for "query/iteration" operation is now "PollableSet::get_ready_pollable". Backward compatibility has been dropped because the Messaging submission has not yet been published. See also the rational below. > Issue 3052: CORBA::PollableSet::poll and CORBA::Poller::is have same semantics > > Summary: 1. The operations CORBA::PollableSet::poll and CORBA::Poller::is_ready > both have the same semantics: verify if a reply message is available and can be > retrieved. The first one works on a set of pollers, the second one on a single > poller. -> The naming of these operations should therefore be consistent. Proposed Resolution: -------------------- The following changes are referring to document ptc/00-02-05. p. 1-41, change "In this example, after the PollableSet::poll indicates that a particular Poller has finished, the code makes the call on the type-specific poller in a non-blocking manner and doesn From: Bill Binko To: Messaging-Rtf Subject: Discussion Issue 3052: CORBA::PollableSet::poll and CORBA::Poller ::is have same semantics Date: Wed, 22 Mar 2000 12:29:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: H%h!!jH~!!TnQ!!_'*!! Just to make sure: we are just talking about changing the name from poll() to get_ready_poller() right? If that is the only issue, I will probably abstain for the following reasons: 1) We have not implemented Pollers at this time and as such have no investment in the name 2) While it seems more clear with the change, we don't really think the old words are THAT bad 3) I have no intention of changing interfaces underneath someone who has implemented it. I can be swayed against this one if the consensus of people who have working implementaitons can show that this will impact them negatively. Binko From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Wed, 22 Mar 2000 19:17:43 +0100 Message-Id: Subject: RE: Discussion Issue 3052: CORBA::PollableSet::poll and CORBA::Poller ::is have same semantics MIME-Version: 1.0 TO: Bill.Binko@trcinc.com, messaging-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Wed, 22 Mar 2000 19:17:42 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Wed, 22 Mar 2000 19:17:42 +0100" X-UIDL: *gf!!5hd!!#J+!!E<$e9 > -----Original Message----- > From: Bill.Binko [mailto:Bill.Binko@trcinc.com] > Sent: Wednesday, March 22, 2000 6:29 PM > To: messaging-rtf > Cc: Bill.Binko > Subject: UNAUTHENTICATED: Discussion Issue 3052: > CORBA::PollableSet::poll and CORBA::Poller ::is have same semantics > > > Just to make sure: we are just talking about changing the > name from poll() > to get_ready_poller() right? Yes, you are correct. > > If that is the only issue, I will probably abstain for the following > reasons: > > 1) We have not implemented Pollers at this time and as such have no > investment in the name > 2) While it seems more clear with the change, we don't really > think the old > words are THAT bad > 3) I have no intention of changing interfaces underneath > someone who has > implemented it. > > I can be swayed against this one if the consensus of people > who have working > implementaitons can show that this will impact them negatively. As the messaging spec has not yet been officially published, the current RTF work is close to the task of an FTF, therefore backward comptability was felt "overkill". Of course, existing Messaging implementations can choose to support smooth migration paths by also allowing the old signature. The same applies to 3053, returning the return value as a return value. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11