On 02.07.2010 09:07, Joe Hildebrand wrote: > On 6/30/10 10:28 AM, "Adam Ruppe" <destructiona...@gmail.com> wrote: > >> For servers, they are still pretty useful. You can use the select() >> call on unix to wait for any one of a set of connections to be ready >> for you, and when it is, you then call the same blocking read/write >> functions. Since you know ahead of time that they are ready, it >> doesn't actually wait. > > Select has been out of favor for quite a while in favor of poll, epoll, > kqueues, IO Completion ports, and the like. I'd recommend starting with > libevent2 (http://monkey.org/~provos/libevent/) if the license fits, and > fire events through the D concurrency mechanisms. > > Layering blocking APIs on top of this should be pretty easy. > Just wondering, as libevent was already brought up on the newsgroup some time ago, is there a special reason to use libevent instead of libev? Both seem to be actively developed and liberally licensed (libevent: 3 Clause BSD libev: 2 Clause BSD), but at least for libevent1 libev claims to be faster. Some new benchmarks against libevent2 ( http://lists.schmorp.de/pipermail/libev/2010q2/001033.html ) show no big difference in speed anymore (libev is still faster when using timeouts or many clients). So any special reason to use one rather than the other?
-- Johannes Pfau
