|Anonymous | Login||2020-08-05 21:55 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0001165||[1003.1(2008)/Issue 7] Base Definitions and Headers||Editorial||Enhancement Request||2017-10-22 10:35||2019-01-28 18:26|
|Section||aio.h, sys/select.h, poll.h|
|Final Accepted Text|
|Summary||0001165: What is the working group's plan for stateful polling (e.g., kqueue, epoll), event loops (libuv) and coroutines (C++2a)?|
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.
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.
|Tags||No tags attached.|
|The Austin Group would welcome a fully formed proposal along these lines, including support from the current maintainers of whatever package is selected. See also https://www.opengroup.org/austin/docs/austin_sd6.txt [^] for guidelines on submitting new material.|
Considering that libuv is the most popular implementation, counting GitHub watchers/stargazers, I filed this issue: https://github.com/libuv/libuv/issues/2164 [^]
Will contact the libev/libevent folks in case libuv declines.
|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|
|2017-10-22 10:37||EdSchouten||Description Updated|
|2018-02-25 22:23||tn||Issue Monitored: tn|
|2019-01-28 16:59||nick||Note Added: 0004233|
|2019-01-28 18:26||EdSchouten||Note Added: 0004234|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|