The following issue has been SUBMITTED. ====================================================================== http://austingroupbugs.net/view.php?id=1165 ====================================================================== Reported By: EdSchouten Assigned To: ajosey ====================================================================== Project: 1003.1(2008)/Issue 7 Issue ID: 1165 Category: Base Definitions and Headers Type: Enhancement Request Severity: Editorial Priority: normal Status: Under Review Name: Ed Schouten Organization: User Reference: Section: aio.h, sys/select.h, poll.h Page Number: n/a Line Number: n/a Interp Status: --- Final Accepted Text: ====================================================================== 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 of the C ecosystem. For example, the Node.js framework allows you to design fully event-driven applications in Javascript. The upcoming revision of the C++ standard, currently referred to as C++2a, will likely contain support for coroutines. As the Coroutines TS has already been implemented in MSVC and Clang, people are already building awesome things on top of it.
Though these frameworks are already out there and work well, practice has shown that the relevant APIs we have in POSIX (aio, poll, select, etc) are insufficient to implement them. They scale badly as the number of registered events increases (see https://en.wikipedia.org/wiki/C10k_problem). This is why most POSIX-like operating systems provide additional polling interfaces: BSD kqueue, Linux epoll, Solaris event ports, etc. I think this clearly demonstrates a disconnect between what's in the standard and what people want. 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 (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 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 redesign, simplify and optimise their polling frameworks without breaking existing applications. 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 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 many modern projects like Node.js, GRPC, etc. It also has a relatively compact, well documented API and a very healthy development community. 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? 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. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2017-10-22 10:35 EdSchouten New Issue 2017-10-22 10:35 EdSchouten Status New => Under Review 2017-10-22 10:35 EdSchouten Assigned To => ajosey 2017-10-22 10:35 EdSchouten Name => Ed Schouten 2017-10-22 10:35 EdSchouten Section => aio.h, sys/select.h, poll.h 2017-10-22 10:35 EdSchouten Page Number => n/a 2017-10-22 10:35 EdSchouten Line Number => n/a ======================================================================
