Are closed fd's being polled? about usockets HOT 8 CLOSED

EAGAIN is intended, ENOENT is not intended but probably part of libuv. You can try the same with the raw epoll and there shouldn't be any of those

from usockets.

I tested with raw epoll and it is clean. With libuv I get the same issues you post here. So looks like libuv is broken.

from usockets.

ENOENT op was EPOLL_CTL_MOD or EPOLL_CTL_DEL, and fd is not
registered with this epoll instance.

It doesn't have to be a bug, can just be inefficient use of epoll_ctl. As long as the error is not EBADF it doesn't have to be a bug. EBADF would definitely be a critical bug.

from usockets.

It doesn't have to be a bug, can just be inefficient use of epoll_ctl. As long as the error is not EBADF it doesn't have to be a bug. EBADF would definitely be a critical bug.

While that might be true, you probably know best as creator of this library. It might still be a thing affecting high performance. Your library is optimized so much for the best possible throughput that an inefficiency anywhere in the stack likely leads to a measurable performance regression.

Is there a runtime environment variable i can set to measure this without recompiling this all the way up to uWebSockets js? Just curious to know what the raw epoll version would do in tersm of req/sec.

from usockets.

It's libuv, nothing we can do about it

from usockets.

You ran it with raw epoll, right?
How?

from usockets.

Uwebsockets.js always runs with libuv because its the event loop of nodejs. The C++ lib itself defaults to raw epoll.

from usockets.

Ah, that makes sense! Thank you for explaining.

Feel free to do whatever you want with this issue. The way i see it there might be a bug somewhere. But you can also argue the bug is upstream in libuv. It's up to you.

from usockets.