emersion
a month ago
My go-to small event loop library is https://github.com/any1/aml
C-events, yet another event loop, simpler, smaller, faster, safer
95 pointsposted a month ago
by thetechstech14 Comments
mgaunard
a month ago
Why not io_uring? That's the biggest game changer.
I guess because it's not possible to abstract away as much.
immibis
a month ago
io_uring works fundamentally differently from polling loops and closer to Windows' IOCP (which is awesome and better than everything that existed on Linux for many years). With a polling loop you wait for data to be available in buffers, and then once you get the ready event, you copy it from the kernel's buffer to yours. With IOCP or io_uring, you submit a long-running read or write event directly into your buffer. You get the event after the read or write call, instead of before. Because of this, it's not possible to make it a drop-in replacement for poll/epoll.
cryptonector
a month ago
From an abstract API perspective it doesn't matter: it's just fire-and-forget where you call a function that will start some I/O and you associate some sort of event completion notice. The details matter only regarding performance.
immibis
a month ago
For this to work, your API has to be an async I/O API not an event listening API. It can't be "wait for readable" - it has to be "do a read and wait for it"
cryptonector
a month ago
No, it's "launch a read and elsewhere get a completion event".
"do a read and wait for it" is synchronous I/O.
pengaru
a month ago
didn't prevent libuv from adding support for it when available:
manwe150
a month ago
libuv is more nearly designed for adding IOCP-like support to epoll systems than epoll to IOCP (though it can approximate either direction), so adding io_uring was already straightforward, by design
Aside: the wepoll mentioned in this repo is a standalone project extracted libuv, for projects that only desire to support Berkeley sockets and don’t care about other events sources (processes or pipes)
foobarian
a month ago
Is this a Windows lib? The tradeoffs are probably completely different than what we're used to then.
> c-events provides function wrappers to some Linux like functionality, exp. mkfifo for Windows.
kevin_thibedeau
a month ago
void *rwtask(param_t v) {
...
a = v->int_ptr;
...
free(a);
tom_
a month ago
I think it makes sense to leave freeing up to the callback, because then management of the object (whatever it is) is up to the caller rather than the library. It might make sense to reuse it for a subsequent request (one way or another), or have it as part of some larger object, or some other thing - etc.
As for using the stdlib heap rather than some other thing: sure. But the routine allocating the buffer in this case used malloc to allocate it, and therefore freeing it with free seems at least not the worst option. If you want to do some other thing, you should do that instead.
lukaslalinsky
a month ago
I was super interested in the non-assembly coroutine approach, as I'm working on a similar project for Zig, but it turns out it just embeds x86_64 binary. Why is that better than having assembly there?
miguel_martin
a month ago
See also: Nim's std/selectors API - https://nim-lang.org/docs/selectors.html, it supports: "Supported features: files, sockets, pipes, timers, processes, signals and user events." - here's a HTTP server event loop using it: https://github.com/guzba/mummy/blob/master/src/mummy.nim#L11...
cryptonector
a month ago
Nice! I could use this :) (for open source work).
Though I would prefer to have something not based on coroutines.