[Xorp-hackers] Using results from one XRL to respond to another

[Steven Simpson]

Hi,

I've just started looking at some XORP code, with a view to fixing a
certain problem.  We have three XORP processes, A, B and C.  A invokes a
method on B.  To provide the results of this call, B must call C, and
use the results of this 'nested' call.

AFAICT, a client makes XRL method calls asynchronously, i.e. it has to
set up a local callback object for each call, pass that object along
with the call's in-arguments, and then pass control (back) to the event
loop.  The event loop eventually picks up the response, unmarshalls it,
and invokes the callback object with the out-arguments.

In contrast, servers must respond synchronously.  The server implements
a regular C++ method with both in and out parameters.  By the time it
returns, it must have determined the out values.

So if a server method needs to make an XRL call, and use the results of
that call to respond to its own caller, it must set up a callback object
to be passed with its own call, and return to the event loop in order to
receive the results it asked for.  Yet it must have those results before
it returns to the event loop, because they are needed to determine the
results to be passed to its own caller, which have to be set before
returning to the event loop.

This surely isn't so unusual that it's never come up before.  Is there a
standard idiom for dealing with it?  If not, I can see several alternatives:

   1. Change the interface on B so that A must have its own interface,
      and A must specify a method on it to be called when B finally gets
      the results of the nested call.
   2. Before B returns to the event loop, it invokes the event loop
      repeatedly until its own callback is serviced.  Perhaps this is
      the recommended idiom...?
   3. Redesign the code generator so that the Xrl*TargetBase class
      contains methods to be provided by the implementation that receive
      the in-args plus a call-back for the out-args.

Option 3 is likely to require more time than we have available to deal
with this problem.

Option 2 assumes that the event loop is re-entrant; the event loop will
be calling the application code, which will call the event loop.  Is
that safe?  Is it guaranteed by specification?  I think it would also
have some potentially unwelcome side effects.

Option 1 is inconvenient for us, but probably the quickest option if (2)
is not possible.

Thanks,

Steven