Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hooray for the Sockets Interface

blog.apnic.net

Post reply on HN
Print view View original

71–80 of 86 posts

Re: Hooray for the Sockets Interface

#71

Post by inigyou »

jchw wrote: post #67
inigyou wrote: post #64

Earlier quoted context omitted.

That's systemd limitations. Who even uses systemd?

> That's systemd limitations. It's kind of the opposite, systemd-logind provides better seat management than without. I attempted to implement the same concept using libseat and seatd unsuccessfully though I do not remember exactly what I got caught on. (not in kwin but a toy compositor; I have been at this problem for a little while now.) That said, most desktop systems have only implemented systemd-logind in a limi…

Then it's libseat and seatd limitations. Why rely on a system that doesn't do what you want? Bypass it and DIY what you actually want.

Re: Hooray for the Sockets Interface

#72

Post by cyberax »

inigyou wrote: post #70
cyberax wrote: post #68

Earlier quoted context omitted.

Happy Eyeballs was a bad fit for network-level implementation exactly because of sockets. But there's nothing inherently app-level about using multiple probing connections in parallel and then selecting the best one. If the IPv6 authors specified this behavior in the original IPv6 RFCs, we would have taken this behavior for granted. After all, why would you expect every program under the sun to deal with all the poss…

Why would you implement multiple concurrent connections at the network level instead of making the one single connection work well?

Because there's no way to make that one connection that works well. IPv6 transitional state is fundamentally less stable than IPv4.

If you mean that one connection should be able to use multiple address families and addresses, then yes. It would be great, but at a much higher complexity than just making several connections at once and then discarding all but the first succcessful one.

Re: Hooray for the Sockets Interface

#73

Post by pjmlp »

adrian_b wrote: post #50
inigyou wrote: post #27

Earlier quoted context omitted.

Windows NT had overlapped IO decades before Linux. The Microsoft kernel team were alright.

Mechanisms equivalent with the overlapped I/O of Windows NT (1993) already existed 30 years earlier, e.g. in IBM OS/360 and PL/I (1964/1965). The main features that were better in Windows NT than in the UNIX-derived operating systems were inherited from the DEC VAX/VMS operating system (1978) (e.g. WaitForMultipleObjects) and a part of them had been inherited from the even earlier operating system DEC RSX-11M (1974-1…

Including the use of systems programming languages with bounds checking, PL/I, PL.8, PL/S, NEWP, ...

Re: Hooray for the Sockets Interface

#74

Post by jchw »

inigyou wrote: post #71
jchw wrote: post #67

Earlier quoted context omitted.

> That's systemd limitations. It's kind of the opposite, systemd-logind provides better seat management than without. I attempted to implement the same concept using libseat and seatd unsuccessfully though I do not remember exactly what I got caught on. (not in kwin but a toy compositor; I have been at this problem for a little while now.) That said, most desktop systems have only implemented systemd-logind in a limi…

Then it's libseat and seatd limitations. Why rely on a system that doesn't do what you want? Bypass it and DIY what you actually want.

I personally use a systemd-based distro (NixOS) and logind is able to handle this use case. The point of trying to support libseat was for the sake of non-systemd distros. (Though elogind would probably work too.)

I certainly wouldn't DIY this; nothing would support my DIY version, which would defeat the purpose.

Re: Hooray for the Sockets Interface

#75

Post by celiacFun »

jchw wrote: post #10

I have two complaints about sockets: 1, bidirectional sockets probably should've been ≥2 fd's, not 1. 2, non-blocking semantics and poll/select suck. Can't blame anyone in 1983 for not getting "async I/O" right since we're still struggling; at least now we have some decent answers (like io_uring on Linux.)

I just can’t understand why the Linux kernel has avoided tracking completions for so long and has such hard time with async I/O. Windows has had IRPs and overlapped I/O for decades, asyc is the default and there just isn’t much reason to ever use synchronous I/O.

Re: Hooray for the Sockets Interface

#76

Post by celiacFun »

adrian_b wrote: post #48
zbentley wrote: post #38

Earlier quoted context omitted.

> non-blocking semantics and poll/select suck. I'd argue that it's not that the semantics suck, it's that there are too many of them. We have O_NONBLOCK, multiple multiplexers (for sane reasons--I don't begrudge 1980s folks for not thinking about fd set size and copy overhead for select(2) either), and others. What's worse, they don't all work with all FDs--not only are regular files not nonblock-able in the same way…

Allready in 1983, 4.2BSD had 3 different attempts at doing multiplexed/asynchronous I/O: Non-blocking I/O: "O_NONBLOCK" with "EWOULDBLOCK" (or "EAGAIN") Signal-driven I/O: "O_ASYNC" with "SIGIO" Synchronous I/O multiplexing: "select()" All 3 had various defects, especially with a large number of concurrent I/O actions. In UNIX-derived operating systems, after 1983 there have been many other attempts to implement some…

Windows has a better async I/O implementation than Linux and has for decades

Re: Hooray for the Sockets Interface

#77

Post by celiacFun »

adrian_b wrote: post #50
inigyou wrote: post #27

Earlier quoted context omitted.

Windows NT had overlapped IO decades before Linux. The Microsoft kernel team were alright.

Mechanisms equivalent with the overlapped I/O of Windows NT (1993) already existed 30 years earlier, e.g. in IBM OS/360 and PL/I (1964/1965). The main features that were better in Windows NT than in the UNIX-derived operating systems were inherited from the DEC VAX/VMS operating system (1978) (e.g. WaitForMultipleObjects) and a part of them had been inherited from the even earlier operating system DEC RSX-11M (1974-1…

I’m not sure you can call anything in Linux/Unix as equivalent to overlapped I/O in Windows given that there aren’t any IRPs

Re: Hooray for the Sockets Interface

#78

Post by celiacFun »

jchw wrote: post #32
inigyou wrote: post #27

Earlier quoted context omitted.

Windows NT had overlapped IO decades before Linux. The Microsoft kernel team were alright.

Windows NT had many things decades before Linux, I've gotten used to it. There are things Windows has that I still sort of wish Linux had, I mentioned one of them just last night (RDP fast user switching/session roaming.) If we're just strictly talking about low level things, another good one would be synchronization primitives, which I guess we now have some of in Linux verbatim at this point, if only for the sake o…

Windows strengths: IRPs and fantastic async I/O, ETW events, tooling- windbg xperf driver verifier time travel debugging, RDP, doesn’t claim everything acts like a file

Linux strengths: file system, open source ecosystem, ssh, lockless algorithm support

Re: Hooray for the Sockets Interface

#79

Post by zbentley »

inigyou wrote: post #63
zbentley wrote: post #38

Earlier quoted context omitted.

> non-blocking semantics and poll/select suck. I'd argue that it's not that the semantics suck, it's that there are too many of them. We have O_NONBLOCK, multiple multiplexers (for sane reasons--I don't begrudge 1980s folks for not thinking about fd set size and copy overhead for select(2) either), and others. What's worse, they don't all work with all FDs--not only are regular files not nonblock-able in the same way…

What would all the other FDs be instead? Like an eventfd or epoll handle, it obviously couldn't be an FD so what would it actually be?

Sorry, what I meant was that FDs that aren’t sockets should be uniformly handled by the async IO syscalls rather than having to parse man pages or trip over EINVALs to figure out the answers to questions like “can I select(2) on a pidfd? Can I O_NOBLOCK a regular on-disk file?”.

For a concrete example, I should be able to select/poll/epoll any file descriptor. The multiplexers can short-circuit return for things where readiness is inherent (e.g. block device files/vfs, I’m not asking for the moon a la waiting for NFS shares to report ready or something).

I should be able to issue non blocking reads on special file descriptors (timerfds, signalfds, eventfds, and so on).

This is analogous to my other unachievable fantasy: everything that exposes a filesystem interface must work with inotify/kqueue/whatever. No exceptions for procfs/NFS/etc.

At some point this fantasizing just becomes me griping about what made it to market/the worse-is-better philosophy generally, though. And yet it moves, I guess!

Re: Hooray for the Sockets Interface

#80

Post by jchw »

celiacFun wrote: post #76
adrian_b wrote: post #48

Earlier quoted context omitted.

Allready in 1983, 4.2BSD had 3 different attempts at doing multiplexed/asynchronous I/O: Non-blocking I/O: "O_NONBLOCK" with "EWOULDBLOCK" (or "EAGAIN") Signal-driven I/O: "O_ASYNC" with "SIGIO" Synchronous I/O multiplexing: "select()" All 3 had various defects, especially with a large number of concurrent I/O actions. In UNIX-derived operating systems, after 1983 there have been many other attempts to implement some…

Windows has a better async I/O implementation than Linux and has for decades

No, although this was true until around 2019 when Linux introduced io_uring and finally had a genuine innovation. io_uring wound up giving us a unified asynchronous I/O layer that handles just tons of things. (And it is genuinely a step up from the overlapped I/O APIs of Windows, as it avoids eating syscall transition overhead in many cases.)

Of course, Microsoft then went on to introduce IORing in 2022, continuing their legacy of never being afraid to adopt good ideas. But still - it would be wrong to suggest Linux is currently behind on async I/O. It hasn't been for years.

Post reply on HN