[Xorp-hackers] Boost use

[Bruce Simpson]

Ben,

Suddenly very busy -- comments inline

On 04/26/10 18:12, Ben Greear wrote:
>
>> Why reinvent when you can reuse?
>
>
> If I re-write it, I can optimize it exactly for my needs, including 
> adding
> any debugging logic or similar that I see fit.  And, I can read the 
> entirety
> of the code and know that it is exactly the same on all platforms and 
> OSs,
> regardless of what someone else might have installed on their OS.

class libraries are a fact of any professional C++ developer's life--
if one does not value one's time well, or if one is looking to learn,
then reimplementing something makes sense--

but it's uneconomic, if solutions are there ready to go.

Glad you have found shared_ptr.hpp and started exploring it--
it is difficult to improve on the pattern which has already been realized,
and I for one researched this thoroughly before advocating it

>
>> Do you honestly expect a developer under pressure to deliver rapidly,
>> to not make the mistake of misreading a & symbol?
>
> There are all sorts of ways to write broken code, and bugs will go into
> the system, but we can fix the bugs..and can review the code as it goes
> in to check for that sort of thing.
>
> I do expect developers to know the difference in value v/s ref, but if
> they don't, I'm more than happy to explain it to them and/or fix the
> bugs myself.

So this use of XORP is largely an educational exercise,
vs delivering a production router suite?

That's cool and someone should do that,
but the new game plan needs to be made explicit if that is the case

I appreciate there are varying levels of C++ expertise in this group --
however am wary of lowering the bar too far--
and XORP Inc eng team's experience bears this out (they also had varying 
levels of C++)

Sadly XORP is to C++ as James Joyce is to a tabloid newspaper,
it is an epic work and tries to make use of the language fully.

As you know my views on this are strong,
that we should have been looking to limit necessary use of C++ from the 
outset,
where it isn't actually needed in the system--

Templates are not going away; they are not an automatic foot-shooting 
device,
as many may well believe. Think of C++ as a surgeon's scalpel

However time is always against us. My argument viz typo still stands

>
>> Shared memory allows "one app to corrupt another" if and only if page
>> mappings fail a bounds check, this would either be due to software
>> failure in the app's mappings, or a serious kernel security regression.
>
>
> The data in the shared memory can be corrupted, and requires locking 
> and/or
> message passing to keep that from happening.  I prefer to keep the 
> apps' memory completely
> separate, or merge them completely into the same single-threaded binary.

Sure,
any communications channel is subject to the possibility of protocol failure

Shared memory poses specific problems precisely because it is a shared 
medium;
serialization still happens, just further down in cache/TLB land;
this is what tokens / generation numbers / atomics are for

If you examine Boost.Interprocess you'll see the atomics are already there.

No getting away from it, Xen widely makes use of 'grant tables' -- same 
thing

but a widely deployed class library,
which encapsulates these operations, and is thoroughly tested,
is unlikely to suffer from what is called out here as a possible issue

A single-threaded binary is even less likely to scale to multicore--
this is in effect advocating ditching the architecture -- ain't gonna 
happen--

and event channels are subject to all sorts (some like to use lockless 
queues to do this)

>
> The one part of bgp/harness logic that seems like it could feed MRTD 
> data uses
> non-batched XRL commands, so it's definitely going to be slow.  But, I 
> might could
> load on one xorp, and then have it peer with another and test that 
> peer sync.

That is probably a better solution--
once again sorry that BGP harness couldn't be fixed on XORP Inc account,
my former client's focus shifted

>
>
>>> Again, XRL may not be perfect, but it seems relatively fast as is,
>>> and there are several easy memory new/delete optimizations waiting
>>> for an hour or two of time to implement.
>>
>> "Relatively fast" -- have you benchmarked this in a real app?
>
> I tested with the xorp XRL sender/receiver test.  I also looked
> at code in bgp, and it all seems serialized (one XRL request at a
> time outstanding).  That means select, send, (process wake on 
> receiver, including
> flushing cache), select, receive, process-data, send result for every 
> XRL request.
> The original sender does no further work until it gets the response 
> back, and receiver does no
> work until it gets the next request.
> Batching would be a huge improvement here.

Yes it should lead to some improvement
and was implemented on the XORP, Inc corporate branch to my knowledge

There's nothing fundamentally wrong with how libxipc interfaces to other 
code--
but what is an issue is that XRL is largely its own thing,
and was mend/make do at the time (before better alternatives came along)

Refactoring is still a change cost.

>
> Sure, but that doesn't mean it's the IPC transport that is to blame.

Cycle for cycle, "something is not quite right in the state of XRL" to 
borrow from Shakespeare

>
> Clearly documented is nice, but doesn't mean it isn't a learning curve.

The learning curve for something which is now established practice in a 
professional field,
is still substantially less than bespoke practice

>
> When it emerges, and 5 years later when most distributions have supported
> it for a few years, then I'd have less complaints, though I still 
> don't like
> using large opaque packages unless I really have to.

Toolchains are large opaque packages, and as above
class libraries are a fact of any professional C++ developer's life--
not building model airplanes in shed anymore

regards
BMS