rework system layer event loop

[mspang]

Problem

The code in src/{system,inet} is based on use of the select(2) system call.

Unfortunately, select(2) is incompatible with event loops used in many modern programs, e.g. those based on abstractions such as those provided by libevent / libev / libuv or that directly use low level event based facilities such as Linux's epoll(7).

The main issue is that these event loops are based on persistent event subscriptions, while select(2) has no persistent state and instead requires calling each entity that's interested in polling for every main loop iteration. This is a major impedance mismatch that complicates integrating CHIP into programs.

Another, lesser problem is the use of fd_sets which imposes a relatively low limit on file descriptor value.

Proposed Solution

• Generalize the system layer to support modern event loops
• Adopt a suitable event loop abstraction for in-repo examples and tests. e.g. libevent
• Strawman Alternative: Use libuv, which also provides a straightforward path to native Windows support.

Ideal outcome - CHIP's IO thread can be removed, and tests/examples are all single threaded

[mspang]

@cecille @kpschoedel @turon

[mspang]

@tcarmelveilleux

[turon]

I agree that moving Linux to a more event based model that aligns with RTOS platform abstractions would be ideal.
The issue is how to do this in a way that is easy to integrate into apps that are based on the various Posix mainloop models (such as select and poll variants).

[cecille]

@mlepage-google - what are your thoughts on libuv for this usecase?

[mspang]

@turon Agree we should strive to make it easy to use whatever main loop implementation the application uses natively (whether that be libevent, libev, libuv, glib, etc). Or even select() if the application really does use that.

I believe it will be much easier to map from an event style interface onto a select() backend than the reverse. The problem with going from select() to e.g. epoll is that we are not notified of new sources as soon as they become interesting.. but rather the next time around the loop. So it's effectively impossible to integrate CHIP into these systems without introducing a new dedicated thread for it to run on.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[stale]

This stale issue has been automatically closed. Thank you for your contributions.