CORBA3 — How correlate requests and replies when using pollable sets?

When using the pollable sets, pollers are registered with
PollableSet::add_pollable() and retrieved using
PollableSet::get_ready_pollable(). As pollers are valuetypes they are passed by
copy, thus portable applications must assume that get_ready_pollable() returns
a different poller instance than the one passed to add_pollable(). Thus, with
non-TII, currently there is no portable way to find out how requests
(represented by the pollers returned from sendp) and replies (represented by
the pollers returned from get_ready_pollable ) correlate.

Consider the following IDL:

module Stock
{
interface Quoter

};

and a client that does a 1000 invocations in the style

poller = quoter->sendp_get_quote(portfolio[i].stock_name);
poll_set->add_pollable(poller);

Now, the client could retrieve the 1000 replies in the order:

while(poll_set->number_left() > 0)

;

But how can the client find out which returned quote belongs to which
stock_name?

Possible resolutions:
---------------------
(a) Reconsider the introduction of a correlation id on pollers which can be
used to compare if two pollers are referring to the same request/reply.

(b) Based on the fact that pollable set is locality-constrained and that
valuetypes support sharing semantics (see CORBA 2.3, 5.2.4.2 Sharing
Semantics), it could be required that PollableSet::get_ready_pollable() returns
a pointer to the same valuetype instance as the one passed as argument of
PollableSet::add_pollable().

(c) Close without action, i.e. has to be solved at the application level, e.g.
in our example the application would have to solve this by changing get_quote to

long get_quote(in string stock_name, out string stock_name);

Discussion:
-----------
(c) contradicts with the CORBA Messaging Philosophy that AMI is a mere
client-side issue and that in principle any existing target can be called
asynchronously.

(b) means that we would have two different polling-related correlation
mechanisms:

• one for correlating requests and replies in different processes based on the
  PersistentRequest objref
• one for correlating requests and replies in the same process based on poller
  pointers

(a) means that a generic correlation mechanism is defined that covers both:
intra- and inter-process correlation. This was variant (a) of issue 2803 in the
latest vote. It failed with 5 NO : 4 YES : 3 ABSTAIN.

I could work out two straw men for (a) and (b) for the next vote, or much
better, we could try to discuss this before the next vote and just work out a
straw man for the variant that has better acceptance.

close no change