30 ms·
> without having to think about threads or synchronization. Just pipe data through the channel! I mostly agree with what you're saying, but note having a chan
by life_is_short 10y ago
> without having to think about threads or synchronization. Just pipe data through the channel!
I mostly agree with what you're saying, but note having a channel doesn't mean one stops worrying about synchronization. If two goroutines both started waiting for data from a channel they'd be deadlocked.
- tscs37 10y agoTrue, on the other hand, go will take care of that to some extend and terminate if all go routines have been deadlocked. Which means well-designed services will remain available even if only with degraded performance.
- life_is_short 10y agoI didn't know go can do deadlock detection. Thanks for this, I learned something new today.
- tscs37 10y agoit's not a 100% detection. You can certainly pile up deadlocked go routines, but the way most libraries (including the standard library) are setup, if you were to write some server, you'd only deadlock on the request but the app keep running. There is no way to reliably detect that but the service will probably service most requests if you didn't plain deadlock everything. If all go routines are deadlocked, the runtime will terminate the service. It's a kind of graceful and somewhat safe degradation.