[Xorp-hackers] rtrmgr and TaskManager

[Bruce Simpson]

Ben Greear wrote:
> Well, here's the slow-down I'm seeing..but WTF would someone add a 1-second
> sleep here???
>   

I don't really have time to delve into the Router Manager specifics 
right now, but I'll share some of what's evident from the XRL 
replacement work.

    My guess here is that the Router Manager code is letting the 
EventLoop run so other task(s) can get serviced. At this point in 
execution, the processes are not being started; instead, the XRLs being 
fired off to configure the process during startup, are shimmed.

    One reason why this is required, is because XRL is trying to be 
completely asynchronous. There's a fair amount of complexity in XRL, and 
the Router Manager, to deal with the fact that XRL method resolution 
happens on a per-method basis, and is completely asynchronous. The 
EventLoop needs to be run() in order for things to happen, mostly 
because C++ doesn't have continuations.

    The lack of a synchronous model for coding to XRL, as an RPC 
mechanism, means that we have some complexity in the 'show_*' tools. 
These are also written in C++, because XRL is tied to C++ as an 
implementation language.

    Any XRLs invoked by the Router Manager come from the template files; 
the *.xrls files are used to validate XRL invocation against the 
targets. These are always XRLs of the form 'finder://' which forces the 
resolution to go via the Finder (an indirect method call using the 
textual Finder protocol).

...

I'd argue that the Router Manager really needs to be revisited entirely, 
and it has been in the commercial product, although not to the extent 
I'd argue needs doing to make the routing processes useful outside of 
the framework they're embedded in right now, as the code is realized in 
the community branch.

    It is purely configuration space stuff, and involves a text parser 
for a configuration language, a configuration tree containing the 
current router config state, and the marshaling/pushing of that state to 
and from the routing processes.

    One might argue that it doesn't even need to be written in C++, and 
an object scripting language (e.g. Python, Ruby) would be sufficiently 
mature (and fast) to do what a Router Manager needs to do. All of these 
things could be realized in an OO scripting language.

    Of course, we don't really have free time on the board right now to 
deal with this right off the bat. The timer you mention here as an issue 
probably could be speeded up, however a time gap there is probably still 
necessary to let other callbacks run.

    I'm wary of wading into it too much before a 1.7-RC is cut, although 
if you find that cutting corners in these areas helps, and doesn't 
disturb functionality, it is something we can consider at that time.

cheers,
BMS