3 ms·

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

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.

worik 2y ago
> 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,
- astrange 2y ago
  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.
  - astrange 2y ago
    Forgot to say, the correctly designed ones are called "structured concurrency".
  - p_ing 2y ago
    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.
    - astrange 2y ago
      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.
liontwist 2y ago
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!”
- mschuster91 2y ago
  > 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.
  - liontwist 2y ago
    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
- mzimbres 2y ago
  > 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.
  - liontwist 2y ago
    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.

worik 2y ago

> 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,

astrange 2y ago
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.
- astrange 2y ago
  Forgot to say, the correctly designed ones are called "structured concurrency".
- p_ing 2y ago
  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.
  - astrange 2y ago
    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.

liontwist 2y ago

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!”

mschuster91 2y ago
> 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.
- liontwist 2y ago
  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
mzimbres 2y ago
> 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.
- liontwist 2y ago
  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.