[Xorp-hackers] Boost use

[Ben Greear]

On 04/27/2010 03:23 AM, Bruce Simpson wrote:

>>> 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?

I am merely offering to help review code and help explain mistakes
to people as I find them, regardless of their experience.

I would hope that others will review my code and return the favour,
as I still make mistakes too.

> 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--

It's never too late to start making things better, and adding something
like boost, which appears to use every C++ trick in the book isn't going
in the right direction in my opinion.

> 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

I'll use templates when needed, just don't prefer them when other techniques
are easily available.

W/regard to ref-ptr v/s boost, would there be any difference between passing
a boost smart pointer by ref v/s val and passing a xorp ref-ptr  by ref v/s val?
If I understood the boost logic, you get the same basic behaviour with both.

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

Considering the current cost of IPC, you would be very likely to increase
performance by consolidating xorp processes into a single binary.  I'm
not suggesting to do this because I like that the individual modules are
relatively simple and easy to debug, but just adding more processes is not always
a performance gain.

>> 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

I now have it mostly sorted out in xorp.ct.  As soon as we get 1.7 out and I'm
cleared to submit, I'll push it upstream.  A few bugs crept into bgp since
the tests were disabled (or started being ignored), but I'm fixing them or working
around them as I find them and nothing huge so far.

>> 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)

"Better" is all hand waving until someone posts some actual performance numbers
and/or shows a patch with significant code clean up.

In a volunteer project such as xorp has become, you cannot force people to use
a particular method of development.  If someone posts patches and such, then
whoever or whatever group is in charge can accept or decline the patches based
on merit.  I have ongoing plans to continue to post patches and improve xorp,
and I see no need for boost in my plans.  If you expect to make ongoing contributions
to xorp, then you can post patches that use boost and show the actual advantages.
But, if you do NOT have any plans to contribute in the near future, then don't
expect others to write code using _your_ preferred methodologies.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com