[Xorp-hackers] rtrmgr and TaskManager

[Bruce Simpson]

Ben Greear wrote:
>
> You are welcome to expect me to support it, but then you'll need
> to accept my patches, and I'm liable to get medieval on it :)
> As you can tell, I don't mind changing things I don't well understand :)

Yeah, that's what gets things done in the end.

> And, I'll probably work towards my ideas about desired v/s actual and
> definitely not towards more fine-grained threading (which is what
> that 'continuation' stuff you talk about sounds like to me.)

It is a real problem. Facebook are shipping a C++ concurrency library in 
Thrift which is largely modeled on Java constructs. Fortunately, the 
splice for XORP doesn't need to use this -- you can easily end up with 
several such models which don't overlap.

There have been efforts, around and under the umbrella of the Boost 
project, to come up with better frameworks for implementing state 
machines e.g. Boost.Statechart.

It's kind of sad that in CS education that Java has been pushed over 
languages which force students into a situation where they don't learn 
about computer architecture (I was a bit of a rebel at uni, and spent my 
time learning THIS stuff instead of the syllabus, by that time this 
'dumbing down' element was already happening in Scottish higher 
education -- I could go on and on about how I was reading Jay Sussman's 
'wizard book' at 16, and never touched it at uni, but I'd just sound 
like a bitter geek). Sometimes there is no substitute for a finite state 
machine (FSM), if you want tight code; threads have their own penalties.

Erlang is an interesting exception because they plain did away with both 
notions of coroutine and thread. Tasks are extremely lightweight in 
Erlang, although the scheduler is purely best-effort (at least in the 
openly-available Erlang Open Telecoms Platform (OTP), open sourced by 
Ericsson), and tasks can't even share variables; they communicate by 
message passing.

So they are somewhere between those two extremes -- scheduling is not 
necessarily cooperative.

Erlang also has language framework support for FSMs, and there are nice 
abstractions for tying protocol decode (at a bitfield level) to Erlang 
variables. This just eliminates a whole layer of complexity in the code 
developers have to write for communication apps.

Education is great, more important, the will and intent to just DO 
THINGS, and sometimes that means side-stepping what is known already -- 
or applying it appropriately on a jagged path, a bit like forked lightning.

>   I do
> like select loops with event handling though, and I am continuously 
> grateful
> that there are no pthreads in xorp!

Yes, appropriately threaded code is harder to debug, and inappropriate 
locking can really rain on your parade.

>
> I think joining fea and rtr-mgr into a single process makes a lot of
> sense.  Let the protocols remain separate.

There's a lot of state in there which makes that non-trivial. I've 
played with the idea of making certain components 'in-process servers' 
COM style, i.e. loadable .so's.

Thrift should speed up RPC performance, so I'm not

P.S. Robert Watson is being funded by Google to finish SOCK_SEQPACKET 
for AF_UNIX on FreeBSD which helps. Chrome is using it under the hood, 
it turns out.

There's a little bit of additional complexity in async RPC (both Thrift 
and XRL) to deal with out-of-order delivery. Not fully implemented, though.

And not all kernels will dispatch async in flight. This is where you see 
the design schism between the UNIX-like ones (Linux, BSD) and Windows 
(NT), which is fully async under the hood, and reordering of any local 
IPC can be a real issue (I/O completion ports).


> ...
> Someday I'll add a XORP_WARNING return instead of just OK and ERROR so
> that we can return warning messages w/out failing commands.

More appropriate use of exceptions might be better. Orion has argued 
that removing exceptions keeps the footprint down, I wonder if it's 
worth the churn.

>
> Well, I'm in a position to fix this in my tree, and I'm doing so.
> I've no idea who has position to do that to the public tree if you don't!

My personal agenda is that we have a whole load of stuff in XORP which 
makes it easy for people to do things in the routing space, we just need 
to work on the realization of the goal of folk actually using it.

Got a train to catch...
BMS