Hacker News Reader

Comment by BobbyTables2 | Hacker News Reader

I fully agree.

Synchronous I/O looks appealing for beginners and simple projects. It seems like the simplest path for things where I/O isn’t the primary focus.

Then one suddenly finds themselves juggling ephemeral threads to “background” tasks or such. The application quickly becomes a multi-threaded monster and still suffers responsiveness issues from synchronous use.

The Tower of Babel created from third party runtimes further adds to the mess even for those who try to do better.

View on HN

> Synchronous I/O looks appealing for beginners and simple projects.

Yes. And.

Synchronous I/O is suitable for almost all projects

When it is unsuitable it is catastrophicly unsuitable,

Synchronous I/O is actually better than async for many programs, partly because almost all async systems were designed without thinking about priority inversions and can't resolve them properly. If you have futures, you have this problem.

Since the NT kernel is async throughout, it solves this with periodic priority boosts for non-running but runnable threads.

I swear, the kernel designers just need to look at NT :-P But we're well beyond a complete rewrite of old kernels, sadly.

That can work but I think it's cheating. Especially if your scheduling is tied into power management or you have high/low power cores, then boosting the low priority threads will waste power.

Forgot to say, the correctly designed ones are called "structured concurrency".

The entire unix operating system is designed to abstract away async problems and turn them sync so you can write sane code (if, else, for).

In my experience simple blocking code is incredibly misunderstood. Most programmers stop their thinking at “blocking is slow and non blocking is fast!”

> The entire unix operating system is designed to abstract away async problems and turn them sync so you can write sane code (if, else, for).

That only works for workloads that can be independently parallelized. For stuff that cannot be - which is the majority of consumer workload - you're in for a world of pain with locking and whatnot other issues.

No. It’s almost all the time that your computer has more than one thing to do;

- your browser uses a process per tab - your web server responds to multiple requests in parallel - your web app is going to launch other programs - your desktop ui is going to have a compositing server separate from each application - your compiler is going to work on multiple source files

> In my experience simple blocking code is incredibly misunderstood.

I don't think so. You can't even implement a full-duplex protocol properly with sync IO since reading and writing can't happen at the same time on the same thread. Splitting them to different threads also won't help since accessing shared state requires synchronization with e.g. mutex that kills again simultaneous reading and writing.

How do you propose to implement duplex IO? And what’s the example case?

With threads the reading and writing can happen simultaneously. The synchronization is only on whatever data you need to share.

Note that if reading and writing are dependent, then single thread actually makes sense because you can’t do one without the other.

Otherwise the pattern of logic you will execute for reading or writing is completely different, which is why threading is the perfect abstraction.

I implemented split IO with io_uring, epoll and eventfd and my own thread safe comm pattern

You can write to an eventfd to wake up io_uring listening on an epoll instance.

Reply on news.ycombinator.com