🎉 Behold the groundbreaking revelation: wrapping #io_uring and #kqueue in a warm, fuzzy blanket to make them "user-friendly" for programmers who apparently can't handle raw I/O. 🙄 Gather 'round, fellow developers, for the riveting journey from blocking I/O to... an event loop that looks suspiciously like every other one you've seen. 🤦‍♂️
https://tigerbeetle.com/blog/2022-11-23-a-friendly-abstraction-over-iouring-and-kqueue/ #userfriendly #programming #eventloop #HackerNews #ngated

A Programmer-Friendly I/O Abstraction Over io_uring and kqueue

https://tigerbeetle.com/blog/2022-11-23-a-friendly-abstraction-over-iouring-and-kqueue/

#HackerNews #ProgrammerFriendly #IOAbstraction #io_uring #kqueue #TechBlog

🌘 一個對 io_uring 和 kqueue 友善的程式設計師 I/O 抽象層
➤ 從阻塞式 I/O 到高效事件驅動模型
✤ https://tigerbeetle.com/blog/2022-11-23-a-friendly-abstraction-over-iouring-and-kqueue/
本文探討了傳統阻塞式 I/O 的侷限性，並深入介紹了 Linux 的 io_uring 和 FreeBSD/macOS 的 kqueue 這兩種高效 I/O 處理機制。作者展示瞭如何利用這兩種機制，將 I/O 操作從使用者空間移至核心空間，大幅減少系統呼叫的開銷。此外，文章提出了一種「中央 I/O 調度」的抽象層，讓開發者無需關心底層的 io_uring 或 kqueue 實作細節，只需透過統一的介面提交 I/O 請求並註冊回呼函式，即可實現更簡潔、更具擴展性的 I/O 處理邏輯，最終建立起一個類似於傳統事件迴圈的 I/O 處理模型。
+ 這篇文章對於理解 io_uring 和 kqueue 的核心概念非常有幫助！作者的
#程式設計 #IO #io_uring #kqueue #效能

I started documenting kernel side #kqueue on #FreeBSD. At this point it is just a brain dump, so I need help improving https://github.com/mekanix/freebsd-src/tree/kqueue-docs. @dexter got any tips except contacting man page author?

@feld @david_chisnall @meka

More generally: #kqueue still has several ragged edges, compared to poll/select.

https://tty0.social/@JdeBP/114574054783681506

https://tty0.social/@JdeBP/114575142459347113

Every little helps in order to fill in all of these gaps.

#FreeBSD

I submitted my #kqueue support for sound(4) on #FreeBSD. I hope we will polish it soon enough. https://reviews.freebsd.org/D53029

cc @JdeBP

🌘 I/O 多工處理：select、poll 與 epoll/kqueue 的演進與效能探討
➤ 從 select 的限制到 epoll/kqueue 的高效能事件驅動架構
✤ https://nima101.github.io/io_multiplexing
本文深入探討了 Unix-like 系統中 I/O 多工處理的演進，從早期的 select 和 poll，到現代高效能的 epoll (Linux) 和 kqueue (macOS)。作者詳細闡述了 select 的 O(n) 時間複雜度和潛在的堆疊溢位風險，以及 poll 如何克服 fd 數量限制但仍存在 O(n) 的效能瓶頸。接著，文章著重介紹了 epoll 和 kqueue 的設計原理，說明它們如何透過事件註冊與回調機制，大幅提升系統的擴展性和效率，特別適用於處理大量併發連線的場景。
+ select 的堆疊問題實在太可怕了！還好有 poll 和 epoll/kqueue 來解決。
+ 這篇文章對
#C #select #poll #epoll #kqueue #網路 #學習 #Linux #kernel #IO 多工

🤔 Oh great, another ex-ad guru turned tech philosopher pontificating on the riveting world of I/O multiplexing. Who knew dodging pop-up ads would qualify you to decipher the cryptic nuances of `select`, `poll`, and `epoll`? 🚀 Maybe next they'll teach us how to cast spells with `kqueue`! 😂
https://nima101.github.io/io_multiplexing #exadguru #techphilosophy #I/Omultiplexing #programminghumor #kqueue #HackerNews #ngated

I/O Multiplexing (select vs. poll vs. epoll/kqueue)

https://nima101.github.io/io_multiplexing

#HackerNews #IOMultiplexing #select #poll #epoll #kqueue

@meka

A quick shufti and it looks like the test program is asking for EVFILT_WRITE and the driver is checking for EVFILT_READ.

#kqueue #FreeBSD

@meka

I was wondering how far you had got with this.

#kqueue #FreeBSD

@jan funnily, the lack of #POSIX #timers in #OpenBSD inspired me to come up with a timer implementation supporting different backends. I was annoyed at first, but didn't regret it. The interface offered by POSIX timers is really clumsy, they can either send some signal or (even worse) launch a thread. My current code only uses them on #illumos, which offers a better signaling mechanism on an "event port". Where available, #kqueue is used for timers. the next fallback is #Linux' #timerfd. And finally, as a last resort, some manual multiplexing on top of #setitimer (cause it's not much worse than "vanilla" POSIX timers).

tl;dr, might be an alternative to contribute code to upstream enabling them to use better platform interfaces for timers...

Please help me spread the link to #swad 😎

https://github.com/Zirias/swad

I really need some users by now, for those two reasons:

* I'm at a point where I fully covered my own needs (the reasons I started coding this), and getting some users is the only way to learn about what other people might need
* The complexity "exploded" after supporting so many OS-specific APIs (like #kqueue, #epoll, #eventfd, #signalfd, #timerfd, #eventports) and several #lockfree implementations based on #atomics while still providing fallbacks for everything that *should* work on any #POSIX systems ... I'm definitely unable at this point to think of every possible edge case and test it. If there are #bugs left (which is somewhat likely), I really need people reporting these to me

Thanks! 🙃

I now implemented a per-thread #pool to reuse #timer objects in #poser (my lib I use for #swad).

The great news is: This improved performance, which is an unintended side effect (my goal was to reduce RAM usage 🙈😆). I tested with the #kqueue backend on #FreeBSD and sure, this makes sense: So far, I needed to keep a list of destroyed timers that's always checked to solve an interesting issue: By the time I cancel a timer with #kevent, the expiry event might already be queued, but not yet read by my event loop. Trying to fire events from a timer that doesn't exist any more would segtfault of course. Not necessary any more with the pool approach, the timer WILL exist and I can just check whether it's "alive".

The result? Same hardware as always, and now swad reaches a throughput of 26000 requests per second with (almost) perfect response times. 🥳

I'm still not happy with memory usage. It's better, and I have no explanation for what I oberved now:

Ran the same test 3 times, 1000 #jmeter threads each simulating a distinct client running a loop for 2000 times doing one GET and one POST for a total of 4 million requests. After the first time, the resident set was at 178MiB. After the second time, 245 MiB. And after the third time, well, 245 MiB. How ...? 🤯

Also, there's another weird observation I have no explanation for. My main thread delegates accepted connections to worker threads simply "round robin". And each time I run the jmeter test, all these worker threads show increasing CPU usage at a similar rate, until suddenly, one single thread seems to do "more work", which stabilizes when this thread is utilizing almost double the CPU as all other worker threads. And when I run the jmeter test again (NOT restarting swad), the same happens again, but this time, it's a *different* thread that "works" a lot more than all others.

I wonder whether I should accept scheduling, memory management etc. pp are all "black magic" and swad is probably "good enough" as is right now. 😆

Getting somewhat closer to releasing a new version of #swad. I now improved the functionality to execute something on a different worker thread: Use an in-memory queue, providing a #lockfree version. This gives me a consistent reliable throughput of 3000 requests/s (with outliers up to 4500 r/s) at an average response time of 350 - 400 ms (with TLS enabled). For waking up worker threads, I implemented different backends as well: kqueue, eventfd and event-ports, the fallback is still a self-pipe.

So, #portability here really means implement lots of different flavors of the same thing.

Looking at these startup logs, you can see that #kqueue (#FreeBSD and other BSDs) is really a "jack of all trades", being used for "everything" if available (and that's pretty awesome, it means one single #syscall per event loop iteration in the generic case). #illumos' (#Solaris) #eventports come somewhat close (but need a lot more syscalls as there's no "batch registering" and certain event types need to be re-registered every time they fired), they just can't do signals, but illumos offers Linux-compatible signalfd. Looking at #Linux, there's a "special case fd" for everything. 🙈 Plus #epoll also needs one syscall for each event to be registered. The "generic #POSIX" case without any of these interfaces is just added for completeness 😆

@meka

One thing not strictly select()-related:

EVFILT_PROC with NOTE_TRACK is another gotcha. It looks great at first glance.

Until one really hammers it with lots of short-lived processes in a deep tree.

Then it becomes apparent that NOTE_EXIT and NOTE_CHILD both use the data field for different purposes, but get merged, and grandchildren get lost from their parents.

https://news.ycombinator.com/item?id=23549116

#FreeBSD #kqueue

@meka

I'm currently working with an old kernel, and I don't know off the top of my head if/when this got fixed. But one of the things is that attempting to add an EVFILT_READ for a file descriptor that is /dev/null results/resulted in an ENODEV EV_ERROR event.

It's generally edge case devices that didn't get attention because a lot of the relevant software still used select() and so no-one (apart from kevent()-everywhere people like me) really hit this.

#FreeBSD #kqueue

@meka

It is always welcome to see more kevent(), if only because it lets other people share my pain, in the hope that that increases the push for kevent() to be fully completed and as good as select().

There are a number of cases I have hit over the years kevent() cannot *quite* do what select() does.

#FreeBSD #kqueue

@jhx Regarding that, at least in theory, it's indeed "truly portable" as it works fine using only #POSIX compliant APIs.

In practice, there can be issues with platforms that don't implement the *full* POSIX feature-set (which is in fact most platforms nowadays). There can also be nasty issues with how feature-test macros are handled (set by the compiler, interpreted by the system's headers) and sometimes with which libraries are needed (unfortunately, POSIX doesn't specify that, e.g. on illumos, you have to link a libsocket for any socket functionality 🙄).

Once I started to add optional support for the platform-specific mechanisms #epoll on #Linux and #kqueue on #BSD (because the POSIX standard select and poll have severe scalability issues), I wanted to also add support for /dev/poll as used on solaris, that's why I installed #OpenIndiana (illumos-based) in a VM to do tests, and I quickly learned /dev/poll was superseded by "event ports", so that's what I added instead.

Unfortunately, I had to do a bugfix release: #swad 0.8

Although I didn't observe any obvious misbehavior on my own installation for several days, I discovered two very relevant bugs just after release of 0.7 🤦‍♂️ -- one of them (only affecting #kqueue, for example on #FreeBSD) even critical because it could trigger "undefined behavior".

Both bugs are regressions from new (performance) improvements added, one from trying to queue as many writes as possible when sending HTTP responses, one from using kqueue to provide timers and signals.

See release notes for 0.8. Don't use 0.7. Sorry 🤪

https://github.com/Zirias/swad