[Xorp-hackers] [PATCH] Supporting asynchronous method implementations

Ben Greear greearb at candelatech.com
Tue Mar 22 16:48:25 PDT 2011


On 03/17/2011 05:58 AM, ss at comp.lancs.ac.uk wrote:
> From: Steven Simpson<ss at comp.lancs.ac.uk>
>
> * Command map and dispatcher declare types for callbacks to pass
>    error code and out-arguments.
>
> * Handlers in generated targets meet these callback signatures.
>
> * Various dispatch methods changed so that out-arguments and
>    error codes are removed from the signature, and the appropriate
>    callback type is added, all to track changes to command map and
>    dispatcher.
>
> * Generated targets include default asynchronous implementations
>    which call synchronous (pure virtual) methods.
>
> * One finder method FinderClient::dispatch_tunneled_xrl is
>    implemented asynchronously.
>
> * Most changes above compiled in only if XORP_ENABLE_ASYNC_SERVER
>    is defined, as set by enable_async_server=True on scons.
>
> * STCP changed from using list of RequestStates in seqno order to
>    map indexed by seqno.  This allows responses to return
>    out-of-order, which is possible if a server implements a method
>    asynchronously.

This patch has been pushed to xorp.ct with a bit of whitespace
cleanup.

I dislike the typedefs and #ifdef'd return values
on principle, but I couldn't think up something better,
so it goes in as is.

If you ever find a way to get rid of some of the preprocessor
code and typedefs, that would be welcome.  Perhaps by making
all calls async at the lower levels, but in the middle layers,
always block until you get the result for sync calls?

Thanks,
Ben


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



More information about the Xorp-hackers mailing list