4 ms·

I think there's a fourth problem that's even more dire: what do you do about blocking? A blocking call stalls the whole system. It doesn't in a non-cooperative

I think there's a fourth problem that's even more dire: what do you do about blocking? A blocking call stalls the whole system. It doesn't in a non-cooperative threading environment. Various languages have "solved" this by not allowing you to use blocking calls and sometimes add syntactic sugar like async/await, but this sucks. The point of having threads is to use them like threads. At least Go gets this right.

kccqzy 6y ago
> Various languages have "solved" this by not allowing you to use blocking calls That is the right solution. Do you seriously think in Go when you make an apparently blocking system call, an actual blocking system call is made? No, you are calling the runtime provided version that doesn't actually block. Of course in C/C++ that needs more discipline to do.
- Blackthorn 6y ago
  > Do you seriously think in Go when you make an apparently blocking system call, an actual blocking system call is made? Who cares? From the perspective of the programmer, it's a blocking call.
  - kccqzy 6y ago
    Then how is a syntactic construct like "await blocking_call()" inferior? I fail to see your point. The await keyword even signals to you the fact that this call may be blocking the progress of the current fiber/coroutine. And back to the original example, it's totally possible for a production implementation to handhold the user like this by, e.g. supplying a modified libc so that all the blocking system calls are linked against the runtime's implementation. That would basically achieve what you liked in Go.
    - Blackthorn 6y ago
      > Then how is a syntactic construct like "await blocking_call()" inferior? It's inferior because you have to actually specify it whenever you make such a call, rather than having the runtime or library be smart and figure it out. > And back to the original example, it's totally possible for a production implementation to handhold the user like this by, e.g. supplying a modified libc so that all the blocking system calls are linked against the runtime's implementation. I know. I didn't say it was intractable. Just like problems 1-3, they all have potential solutions -- they just involve hard work.
      - kccqzy 6y ago
        I see what you mean now. Omitting the keyword "await" is incredibly easy to do; simply do something different when the returned type is an awaitable. But the fact is that most languages haven't done this, and have you considered that perhaps language designers considered this issue and decided that explicit is better than implicit? And there are also a whole host of other issues too.

kccqzy 6y ago

> Various languages have "solved" this by not allowing you to use blocking calls That is the right solution. Do you seriously think in Go when you make an apparently blocking system call, an actual blocking system call is made? No, you are calling the runtime provided version that doesn't actually block. Of course in C/C++ that needs more discipline to do.

Blackthorn 6y ago
> Do you seriously think in Go when you make an apparently blocking system call, an actual blocking system call is made? Who cares? From the perspective of the programmer, it's a blocking call.
- kccqzy 6y ago
  Then how is a syntactic construct like "await blocking_call()" inferior? I fail to see your point. The await keyword even signals to you the fact that this call may be blocking the progress of the current fiber/coroutine. And back to the original example, it's totally possible for a production implementation to handhold the user like this by, e.g. supplying a modified libc so that all the blocking system calls are linked against the runtime's implementation. That would basically achieve what you liked in Go.
  - Blackthorn 6y ago
    > Then how is a syntactic construct like "await blocking_call()" inferior? It's inferior because you have to actually specify it whenever you make such a call, rather than having the runtime or library be smart and figure it out. > And back to the original example, it's totally possible for a production implementation to handhold the user like this by, e.g. supplying a modified libc so that all the blocking system calls are linked against the runtime's implementation. I know. I didn't say it was intractable. Just like problems 1-3, they all have potential solutions -- they just involve hard work.
    - kccqzy 6y ago
      I see what you mean now. Omitting the keyword "await" is incredibly easy to do; simply do something different when the returned type is an awaitable. But the fact is that most languages haven't done this, and have you considered that perhaps language designers considered this issue and decided that explicit is better than implicit? And there are also a whole host of other issues too.