[phobos] std.event / event loop for phobos

[Andrei Alexandrescu]

Would you want to be the leader on Phobos+libev?

Andrei

On 1/2/11 5:27 PM, Masahiro Nakagawa wrote:
> On Mon, 03 Jan 2011 07:51:56 +0900, Andrei Alexandrescu
> <andrei at erdani.com> wrote:
>
>> Two questions:
>>
>> 1. Which is better, libev of libevent?
>
> I think libev is better. libevent becomes libevent2, but performance is
> still even.
> See this mail: http://lists.schmorp.de/pipermail/libev/2010q4/001246.html
>
> In addition, Node.js, Some MessagePack implementations and many projects
> use libev.
> libev has a good record :)
>
>> 2. Which of them is available on Windows?
>
> libev on Windows has some limitations but works.
> However, I don't know the detail of limitations...
>
>
> Masahiro
>
>> On 9/8/10 9:53 AM, Johannes Pfau wrote:
>>> On 08.09.2010 16:02, Masahiro Nakagawa wrote:
>>>>
>>>> I am thinking about std.event.
>>>> This module supports system-dependent APIs(kqueue, epoll, etc...) and
>>>> abstraction layer.
>>>>
>>> I think the best solution would be a wrapper / abstraction layer for
>>> libev. All of the mentioned APIs (kqueue, epoll, select...) are broken
>>> in some way, so writing a new event loop system in D will be painful and
>>> it will take a long time until it gets stable. Also libev already has
>>> support for more event sources (timer, periodic, signal, stat, ...).
>>>
>>> Quoting libev documentation:
>>>
>>> EVBACKEND_SELECT
>>> Not/completely/standard, as libev tries to roll its own fd_set with no
>>> limits on the number of fds, but if that fails, expect a fairly low
>>> limit on the number of fds when using this backend.
>>> This backend maps|EV_READ|to the|readfds|set and|EV_WRITE|to
>>> the|writefds|set (and to work around Microsoft Windows bugs, also onto
>>> the|exceptfds|set on that platform).
>>>
>>> EVBACKEND_POLL
>>> It's more complicated than select, but handles sparse fds better and has
>>> no artificial limit on the number of fds you can use (except it will
>>> slow down considerably with a lot of inactive fds).
>>>
>>> EVBACKEND_EPOLL
>>>
>>> The epoll mechanism deserves honorable mention as the most misdesigned
>>> of the more advanced event mechanisms: mere annoyances include silently
>>> dropping file descriptors, requiring a system call per change per file
>>> descriptor (and unnecessary guessing of parameters), problems with dup
>>> and so on. The biggest issue is fork races, however - if a program forks
>>> then/both/parent and child process have to recreate the epoll set, which
>>> can take considerable time (one syscall per file descriptor) and is of
>>> course hard to detect.
>>>
>>> Epoll is also notoriously buggy - embedding epoll fds/should/work, but
>>> of course/doesn't/, and epoll just loves to report events for
>>> totally/different/file descriptors (even already closed ones, so one
>>> cannot even remove them from the set) than registered in the set
>>> (especially on SMP systems). Libev tries to counter these spurious
>>> notifications by employing an additional generation counter and
>>> comparing that against the events to filter out spurious ones,
>>> recreating the set when required.
>>>
>>> EVBACKEND_KQUEUE
>>> Kqueue deserves special mention, as at the time of this writing, it was
>>> broken on all BSDs except NetBSD (usually it doesn't work reliably with
>>> anything but sockets and pipes, except on Darwin, where of course it's
>>> completely useless). Unlike epoll, however, whose brokenness is by
>>> design, these kqueue bugs can (and eventually will) be fixed without API
>>> changes to existing programs. For this reason it's not being
>>> "auto-detected" unless you explicitly specify it in the flags (i.e.
>>> using|EVBACKEND_KQUEUE|) or libev was compiled on a known-to-be-good
>>> (-enough) system like NetBSD.
>>>
>>> While stopping, setting and starting an I/O watcher does never cause an
>>> extra system call as with|EVBACKEND_EPOLL|, it still adds up to two
>>> event changes per incident. Support for|fork ()|is very bad (but sane,
>>> unlike epoll) and it drops fds silently in similarly hard-to-detect
>>> cases
>>>
>>> EVBACKEND_PORT
>>>
>>> This uses the Solaris 10 event port mechanism. As with everything on
>>> Solaris, it's really slow, but it still scales very well
>>> (O(active_fds)).
>>>
>>> Please note that Solaris event ports can deliver a lot of spurious
>>> notifications, so you need to use non-blocking I/O or other means to
>>> avoid blocking when no data (or space) is available.
>>>
>>> While this backend scales well, it requires one system call per active
>>> file descriptor per loop iteration. For small and medium numbers of file
>>> descriptors a "slow"|EVBACKEND_SELECT|or|EVBACKEND_POLL|backend might
>>> perform better
>>>
>>>
>>> --
>>> Johannes Pfau
>>>
>>>
>>>
>>> _______________________________________________
>>> phobos mailing list
>>> phobos at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos