Starting from wasmer wasmer 4.1, wasmer implements epoll for polling on file descriptors. This syscall was added to improve performance in wasix. However, poll_oneoff is still supported.

The release of wasmer 4.1 introduces epoll support for wasix.

Epoll opens up gates for scalability and improves performance in aspects such as networking, file system access, etc.

What is Epoll?

epoll is a variant of poll available in the Linux kernel, designed to be more efficient when dealing with large numbers of file descriptors. Unlike poll, which scans through all file descriptors each time it is called, epoll uses an event-driven approach. It maintains a watch list of file descriptors, and only those that have changed status since the last call will be returned to the user.

You can learn more about epoll, poll, and select in this article by Julia Evans and this article by LIRAN B.H.

What does epoll bring in for WASIX?

Works on epoll for WASIX have been underway for months and before wasmer 4.1, wasmer runtime used the poll_oneoff syscall for non-blocking operations such as networking, file system access, etc. This meant that we had to fork mio to use the poll_oneoff syscall but found limitations with inconsistencies on how POSIX implements poll and how WASI specified poll_oneoff. Implementing the much more scalable epoll syscall allows for a consistent implementation that matches closer to POSIX without hurting WASI backward compatibility which WASIX is committed to retaining.

This means that:

• epoll scales much better when running lots of file descriptors. E.g. an http server with hundreds of connections.
• The I/O latency is more deterministic and predictable when under heavy load.
• CPU usage is more efficient than poll_oneoff
• The new epoll calls are much more stable as the code paths are cleaner under the hood as they are much closer to how Linux works

To sum up, the bread and butter of an HTTP Server are now more stable and scalable.

Some results from the benchmarks:

As seen above, epoll is much more scalable than poll_oneoff. As the number of connections increases, the performance of epoll shines.

What this means for libraries?

tokio is the most popular asynchronous runtime for Rust. It is used by many libraries such as hyper, actix-web, tide, sqlx, async-std, etc. Its multiplexed I/O is implemented using mio which is a library that provides a cross-platform interface for multiplexed I/O. mio uses epoll and kqueue in its native implementation but implements poll_oneoff for WASI.

The official notes from mio's WASI implementation too state that:

The current implementation is somewhat limited. The Waker is not implemented, as at the time of writing there is no way to support wake-up a thread by calling poll_oneoff.
Furthermore the (re/de)register functions also don't work while concurrently polling as both registering and polling require a lock on the subscriptions.
Finally Selector::try_clone, required by Registry::try_clone, doesn't work. However, this could be implemented by use of an Arc.
In summary, this only (barely) works using a single thread.

Why settle for single-threaded operations when you can harness the blazing power of native tokio in WASIX?

All other libraries that depend on mio or any other library that uses epoll under the hood can reap the benefits of epoll in WASIX.

So what are you waiting for? Go ahead and try out your favorite library in WASIX or start with our examples here.

Please update to wasmer 4.1.1 or above.

Conclusion

With the introduction of epoll in WASIX, we have made WASIX more performant, stable, and scalable. This is a huge step towards making apps more compatible with WASIX.

What's next?

We have also added TLS support in WASIX but this deserves an article of its own. Stay tuned for more updates on WASIX.