Timeline for Why don't programming languages automatically manage the synchronous/asynchronous problem?
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 13, 2020 at 0:08 | comment | added | Frank Hileman | Excellent answer and helps explain why languages using the Erlang BEAM VM don't seem to need C# stye async. | |
| Aug 12, 2019 at 15:37 | comment | added | sunprophit | @LouisJackman isn't it possible to know at compile time whether operation will be blocking or not, i.e. you open all file descriptors with O_NONBLOCK flag | |
| Aug 12, 2019 at 11:57 | comment | added | Louis Jackman | @sunprophit Asynchronous non-blocking is just a compiler transformation (usually async/await), whereas synchronous non-blocking requires runtime support like some combination of complex stack manipulation, inserting yield points on function calls (which can collide with inlining), tracking “reductions” (requiring a VM like BEAM), etc. Like garbage collection, it’s trading off less runtime complexity for ease of use and robustness. Systems languages like C, C++, and Rust avoid larger runtime features like this due to their targeted domains, so asynchronous non-blocking makes more sense there. | |
| Aug 11, 2019 at 9:42 | comment | added | sunprophit | @LouisJackman could elaborate a little on your last statement about async non-blocking for system programming. What are the pros of async non-blocking approach? | |
| Apr 14, 2019 at 20:52 | comment | added | amon | Hmm ok, I do understand your distinction now. Whereas I'm more concerned about managing data- and control-flow between coroutines, you are more concerned about never blocking the main kernel thread. I'm not sure Go or Haskell have any advantage over C++ or Java in this regard since they too can kick off background threads, doing so just requires a tad more code. | |
| Apr 14, 2019 at 11:50 | comment | added | Louis Jackman | I use "asynchronous" and "synchronous" to discuss the programming model exposed to the developer and "blocking" and "non-blocking" to discuss the blocking of a kernel thread during which it can't do anything useful, even if there are other computations that need doing and there is a spare logical processor it can use. Well, a goroutine can just wait around for a result without blocking the underlying thread, but another goroutine can communicate with it over a channel if it wishes. The goroutine needn't use a channel directly to wait for a non-blocking socket read though. | |
| Apr 9, 2019 at 18:34 | comment | added | amon |
This was a really interesting answer! But I'm not sure I understand your distinction between “synchronous” and “asynchronous” non-blocking code. For me, synchronous non-blocking code means something like a C function like waitpid(..., WNOHANG) that fails if it would have to block. Or does “synchronous” here mean “there are no programmer-visible callbacks/state machines/event loops”? But for your Go example, I still have to explicitly await a result from a goroutine by reading from a channel, no? How is this less async than async/await in JS/C#/Python?
|
|
| Apr 9, 2019 at 14:42 | history | answered | Louis Jackman | CC BY-SA 4.0 |