>>108276611
i'm gonna kiss you on the lips

>>108276611
she makes me -mad- hard

>this guy is pretty neat
Dude.

Duuuuuuuuude.

fcntl is literally *everything that is wrong with Linux* - i.e. the fact that a bunch of autists designed a monolithic kernel with a microkernel API that doesn't give a shit about heavy-duty transitions to kernel mode.

It was so bad that they invented a new syscall - accept4 - that allowed people to specify the socket flags for the newly created socket, because servers would inadvertently call fcntl to set the socket into non-blocking mode - but the autists never questioned themselves if people wanted to collect multiple connections at once, via socket buffer. Same as with epoll_ctl.

And then the retards don't treat the API as a compatibility layer, but as the primary, first-class interface to the kernel, and optimize the shit out of it over the course of thirty years, until io_uring (which is a fuckup in and of itself) shows them that it's time to actually provide some monolithic kernel interfaces. Screw these autists.

>>108276611
she makes me mad -and- hard

>>108276955
what's so bad about paying for an extra context switch when accepting a new connection on a socket?

especially if you use stuff like poll or select which are level triggered and will drain performances on every read or write. on the contrary if you use epoll on edge-triggered mode, then you'll always pay one extra syscall for the final read/write to be able to check for EWOULDBLOCK.

I agree that using the kernel for networking on servers is a mistake in general. Especially if you can use DPDK which is day and night in terms of performances. io_uring is still not production ready, it still has many issues, but it should improve with future releases.

fcntl is literally something you call only once per connection and forget about it. it costs about as much as a tlb miss, and you don't pay any extra cost later.

>>108277248
>what's so bad about paying for an extra context switch
One: it's a mode switch, not a context switch. Context switches flush the TLB.
Two: two mode switches. One to enter kernel mode, one to leave it.
Three: it's mode switches *for every connection that comes in*. If, since the last time you accepted connections, there are now 70 more connections that came in, you have to collect every single one of them like a fucking retard, yielding 140 mode switches. Now add to that calls to epoll_ctl and/or fcntl, and you're easily at 420 mode switches.

For something that could've needed six (two for batched accept, two for batched fcntl, and two for batched epoll_ctl).

THAT is the problem.

>>108277336
Also:
>mode switches stall the superscalar pipeline, meaning that reads and writes have to fully retire before the switch is made
>cache and page translation flushes
>shared resources that the kernel has to acquire locks for *every single time before accessing them*

It's the same nonsense as with mmap. Oh, sure we could've locked the page table once, performed a whole bunch of changes, shot down potential translation entries in other processes once, released the lock, and return. But that's not what we got. What we got was ... well, anyone who can use strace can see for themselves.