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

[Ben Greear]

On 02/07/2011 07:10 AM, Steven Simpson wrote:
> 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.

Maybe have the initial response be 'working-on-it', and then pass the info
back with a separate XRL command when the command is completed?  Make
copies of any data you need from the original XRL, including some sort of
key so that the requestor can recognize the real response when it finally
comes.

Thanks,
Ben


>
> Thanks,
>
> Steven
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com