|The following issue has been SUBMITTED. |====================================================================== |http://austingroupbugs.net/view.php?id=1165 |====================================================================== |Date Submitted: 2017-10-22 10:35 UTC |Last Modified: 2017-10-22 10:35 UTC |====================================================================== |Summary: What is the working group's plan for stateful |polling (e.g., kqueue, epoll), event loops (libuv) and coroutines (C++2a)? |Description: |Over the last couple of years we've seen the use of event-driven |programming on UNIX-like systems increase, especially when looking outside ... |for coroutines. As the Coroutines TS has already been implemented in MSVC |and Clang, people are already building awesome things on top of it.
So. It seems you cannot control the number of whatever extension people who can add to the runtime environment. What a pity. ... |The most naïve thing we could do at this point is standardise one of the |polling interfaces mentioned above. Let the Linux folks implement kqueue, |or let the fine people at Oracle implement epoll, we all know that this |approach simply won't get any traction. Apart from technical Why not? I do not know that. |(dis)advantages of any of these interfaces over the other, there is likely |too much pride and history involved. Another issue with this approach is |that the polling interfaces are still fairly low-level. They are a building |block, but don't facilitate event-driven programming directly. | |This is why I propose that POSIX goes into another direction: standardise |an event loop. By doing this, we're not only avoiding the entire discussion What a terrible idea! You even want to take away the possibility to implement the event loop that i need, if any! |about polling frameworks, we're also creating an ecosystem where people can |write portable libraries that can easily be scheduled within the same event |loop, which is awesome. It also gives operating systems the ability to No it is not. How long does it take to write a shallow layer that works on epoll(2) or kevent(2) the way you need it. But standardizing a fixed event requires myriads of possibilities for configuration possibilities of this intransparent black box of a thing. Just look how many people actually use the terrible black box posix_spawn(): how many, i am asking you? And then many frameworks which build upon POSIX do provide their very own abstraction already, for those of you who use graphical desktops, they all have become bottled already i think. It is likely that they continue to use their own entire framework driving event loop, which would need to become hooked onto your new blackbox event loop, or require massive changes. Or continue to use the old system event mechanisms, which exist for quite some time already. |redesign, simplify and optimise their polling frameworks without breaking |existing applications. That is true. However, what could be done differently for epoll, for example, you _create1() "the object", you _wait() for some event, you close the virtual descriptor, which likely is backed with a tree instead of an array, i have never actually looked. Granted, struct timespec could be used for waiting and could be set to the remaining time on return, but vDSO provides timestamping so fast that this seems redundant these days. (Nonetheless you need to be careful to create the wait time, since the timeout argument is a 32-bit, a signed integer, to be exact.) This in turn seems to support my point of view. |Right now there are (at least) three mature event loops written in C in |use, in chronological order: libevent, libev and libuv. The latter has the I have also written one. Simple, but with tick-timers, one-shot timers, periodic timers, and I/O monitors etc. Exactly as needed. We had a tick time, as printed by a tick timer, and nothing to do otherwise, of 2-3 (3) microseconds on Linux and 3-4 (3) microseconds on FreeBSD, on a Cyrix 166+. That was pretty good i thought, giving that gettimeofday(2) took 10 microseconds then. |advantage that its API has been designed in such a way that it can also be |implemented on non-UNIX systems (e.g., Windows), which is why it's used by Yes it can, we use IOMonitors and such, after i have seen how Cygwin fooled around with WaitForMultipleObjects or what its name was, to get the TTY selection done transparently that is to say. |many modern projects like Node.js, GRPC, etc. It also has a relatively |compact, well documented API and a very healthy development community. How nice for them. Much better than JAVA which initially created a thread for each I/O selector! |Desired Action: |Initially, I would like to use this bug report to explore the options. |First of all, I would love to hear the working group's opinion on this |matter. Do they see things the same way? No. I am on the contrary side of yours, absolutely. I hate blackboxes which have to become pumped up with features, i think this completely contradicts the Unix approach of doing things. Entirely. |After that, there are two different things we could do: design our very own |event loop or standardise an existing one. I think the latter makes most |sense, personally preferring libuv. Once an event loop is chosen, we should |try to open a dialog with the maintainers of that respective event loop. You have just recently changed your CloudABI to go this route and have chosen libuv to implement it. Of course it would be _absolutely_ fantastic to have this possibility in the standard, getting event-based I/O notifications! May it be Linux epoll or FreeBSD kevent, the former is more specific with the additional epoll_ctl(), the latter only requires two systemcalls. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
