Live data from Hacker News

Creator of Raft Algorithm introduces LogCabin

sourcegraph.com

1–10 of 53 posts

Re: Creator of Raft Algorithm introduces LogCabin

#4
First thoughts in my head....

1) Ah, cool, creator of Raft algo, so some of the 'obvious' mistakes in an implementation should've been resolved by now (though if ppl weren't trying to use it in production.... who knows).

2) Great, C++, it should be efficient and fast with consistent RAM usage (Go's GC is a bit.... eh... still).

3) Oh, you need a C++ client library. :(

I would love to say that API's don't matter, but they do. So, so, so much. If they didn't, etcd would never have had a chance against Zookeeper. The Zookeeper folks are looking at adding RESTful API's to allow functionality ala-etcd, because its obvious a convenient API is a huge win. Any distributed system solution attempting to gain steam should consider this from the beginning now, as the bar has been set.

Re: Creator of Raft Algorithm introduces LogCabin

#5
I'm not a C++ programmer, and work mainly with Go. I'm curious to know if it is usual for C++ developers to implement their own event loops for network transports, as Diego has done here [0]. The other example I know is Replicant [1], which is used by HyperDex, and it uses a custom event loop too [2].

[0] https://github.com/logcabin/logcabin/tree/master/Event

[1] https://github.com/rescrv/Replicant

[2] https://github.com/rescrv/busybee

Re: Creator of Raft Algorithm introduces LogCabin

#10

I'm not a C++ programmer, and work mainly with Go. I'm curious to know if it is usual for C++ developers to implement their own event loops for network transports, as Diego has done here [0]. The other example I know is Replicant [1], which is used by HyperDex, and it uses a custom event loop too [2]. [0] https://github.com/logcabin/logcabin/tree/master/Event [1] https://github.com/rescrv/Replicant [2] https://github…

LogCabin uses its event loop for network operations but then hands requests off to threads to process. I started out with libevent2, but the problem is it doesn't deal with having multiple threads very well (error-prone and inefficient). It's also not as well-documented as the man pages for epoll, so I ended up using epoll directly instead. What was really lost in the libevent2 -> epoll conversion was platform independence, but I think it might be better to get that back through well-placed #ifdefs or relying on some other library; I wouldn't go back to libevent2.
Post reply on HN