On Sat, Nov 28, 2009 at 10:24 PM, Pedro Melo <me...@simplicidade.org
> I really hope that I don't seem pushy about this, really :), just
> pointing out the advantages. you know much better than I what is the
> best path for Redis.
No problem Pedro, I think your arguments are *valid* and I agree that
libev is a good piece of code after reading the source for a while
today. If we put this issue as a purely software engineering stuff,
that is, supposing we are going to write a component for the Space
Shuttle, no doubt the right thing to do is to pick the safest thing
that works and is well tested.
But there are other possible point of views, and my feeling is that
they are not less important, but are not objective as well. I think
this discussion has some deep link with the most important motivations
for writing software. I think there is some value in simpler code that
does only what is needed and is clean to read. Libraries are a great
idea to accomplish great things in short time, but things like libev
finish to resemble every day more what they wanted to avoid, after
all there was libevent already. Was it buggy? Why don't fix, or at
least fork it? Because libevent is too complex, is a mess, and so
forth. But at the end this libraries, including libev, try to work for
everybody ruining the initial simple design. Need more identical
events registered for the same FD? For me is a design error, for
general libraries is a feature because there are people using such a
feature. And so forth.
There is also some value in not having dependencies. I have not proofs
but I *bet* part of the fact that Redis is starting to get some user
is not *only* due to its merits as a database, but also to the fact
that's so simple to get started. It's simple to understand how it
works, simple to compile, simple to run even without a configuration.
The semantics itself is so simple that I know at least a few people
implementing a Redis clones just for fun in different languages:
If you take the street of simplicity this should be adopted in
everything, from the protocol to the fact there are no dependencies,
and that everybody with some C skill can open ae.c and understand how
an event loop works.
> Of course, no lib is without bugs.
> I can only say that libev is very active and the author responds
> quickly to bug reports on the mailing list.
Yes it's a good project indeed.
>> - I plan to use a lot of timers in the future. All this libs are using
>> an O(N) timer algorithm, at least this is what I see from the sources.
>> A balanced tree or a skiplist is needed to improve over this. When
>> I'll need it I'll develop it without to wait for external developers
>> to merge my changes.
> I believe timers are O(log N), but you can see the algorithm
> complexity section of the documentation:
> Actually, libev is one of the few libraries that *documents* the
> complexity of the algorithms it uses. :)
A very good point about it.
> Anyway, I'm sure it will all work out.
Well I'm not so sure as it's new code, I rewrote almost from scratch
ae.c, but even if there will be bugs and I'll fix it eventually, I
think it's worth the efforts. Btw now I entered feature freeze with
the last commit, and I'll use the next month before to release -rc1 to
read the source code from scratch, and do a lot of testing, this can
Thanks for sharing your ideas,