Re: [conntrack-utils PATCH r7285 00/11] conntrackd with libevent

[Pablo Neira Ayuso <pablo@netfilter.org>]

Max Kellermann wrote:
> On 2008/01/23 13:07, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
>> My experience is that synchronization software is a bit hard because
>> bugs are somehow more difficult to detect (you need a good testbed
>> and QA testing requires a considerable amount of time). If we
>> introduce more source code lines, chances to introduce bugs
>> increase, for that reason I try to keep it as simple as possible.
> 
> I understand, but think about how many critical bugs we fixed in this
> so simple 200 lines alarm implementation.  libevent has proven quite
> stable in the past, many daemons use it nowadays.  We not only use it
> for alarms, but also for socket events (local_server, nfnetlink) and
> for signal handlers.  There is the decision between well-tested but
> complex external code, and on the other hand untested new code, which
> is simple currently but might grow in the future.

You can blame me for those critical bugs during the development, I
should take my time before comitting untested code. We don't use that
many descriptors so conntrackd cannot exploit the main benefit of
libevent IMO.

BTW, there's an implementation of the RB-trees in the kernel under lib/
that seems to be quite stable and which has several clients. We may use
it to implement the alarm scheduler. Moreover it is GPLv2 or any later.
Although I have not investigate it further yet.

> By the way, the libevent migration is not completely finished with my
> patch, run() should be replaced with event_dispatch(), but for this,
> STATE(mode)->run() has to be rewritten to be event driven.  I believe
> this rewrite could make conntrackd even better and cleaner (and
> faster), even if we do not use libevent.

I would apply such rewrite on the fly if it improves the code and
doesn't depend on libevent for now.

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers