On 22/03/11 23:48, Ben Greear wrote:
> 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?
I had a go...
A good dividing line seems to be between XrlDispatcher (lower level) and
XrlCmdMap (middle level). So, XrlCmdMap retains its conditional
declarations, but XrlDispatcher's interface is now unconditionally
asynchronous. I think if I went further, and made XrlCmdMap
unconditionally asynchronous, it would unconditionally spill into the
tgt-gen-erated code, and bloat the binaries.
Internally, XrlDispatcher calls XrlCmdMap, so it must still use
conditionals from xrl_cmd_map.hh.
I'm afraid I made the issue with FinderClient more complicated than
necessary. FinderClient::dispatch_tunneled_xrl calls a dispatcher. It
has now had three forms wrt my patches:
1. Originally, it called a synchronous dispatcher, but if it got as
far as that, it ignored the out-args and return code from the
dispatcher, and always returned OKAY.
2. My previous patch allowed it to call either sync or async
dispatcher, with some ugly macros. In the async case, it used the
return code from the dispatcher (passed through a private callback
supplied to the dispatcher) as its own result, and had to report
this in turn through a callback argument supplied by its own
caller, so it had an async interface.
3. Now it only ever calls an async dispatcher, and unconditionally
needs to supply it with a callback.
Note that, when I wrote the first patch, I hadn't understood that the
original version discarded all results from the dispatcher, and so I had
made the conditional version unnecessarily complex in trying to preserve
that information. In version 3, the callback doesn't actually do
anything - all results are dropped as before - and that means
dispatch_tunneled_xrl can return OKAY immediately after calling the
dispatcher. It therefore doesn't require a callback from its own
caller, so now it has its original (synchronous) interface.
In turn, this means that the FinderClientXrlTarget, which calls
dispatch_tunneled_xrl, is totally reverted to version 1, as it uses
FinderClient's reverted synchronous signature. Blind alley - sorry
about that.
Stripped binary sizes: async version adds about 2MB, as before. [scons
check] has the same results, for most lines containing "Test" (only
diffs are timestamps, PIDs, etc). Patch soon...
Cheers,
Steven
--
_______________________________________________
Xorp-hackers mailing list
[email protected]
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers