Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
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 2022-07-18 16:02
Reporter EdSchouten View Status public  
Assigned To ajosey
Priority normal Resolution Rejected  
Status Closed  
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
Summary 0001165: 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.
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0004233)
nick (manager)
2019-01-28 16:59

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.
(0004234)
EdSchouten (updater)
2019-01-28 18:26

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.
(0005896)
Don Cragun (manager)
2022-07-18 16:02

Since no full proposal has been submitted, this bug is rejected. If a full proposal is available at a later date, please file a new bug with the details.

- 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
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
2022-07-18 16:02 Don Cragun Interp Status => ---
2022-07-18 16:02 Don Cragun Note Added: 0005896
2022-07-18 16:02 Don Cragun Status Under Review => Closed
2022-07-18 16:02 Don Cragun Resolution Open => Rejected


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker