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 _______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
