Насколько я понимаю, goroutines блокирует запуск других goroutines, если они слишком заняты. Для меня это означает, что производительность и отзывчивость моего приложения, вероятно, будут зависеть от меня, зная, какие методы библиотеки будут обеспечивать контроль над другими goroutines (например, обычно Read() и Write())
Есть ли какой-либо способ, который я могу точно знать, как различные методы библиотеки будут получать контроль над другими goroutines, то есть фактически не блокировать?
Есть ли способ реализовать новый метод, который вызывает сторонний код (включая асинхронный Win32 API, такой как findnextchangenotification, который полагается на waitforsingleobject или waitformultipleobjects) и ведет себя "хорошо" с планировщиком Go? В этом конкретном примере syscall будет сигнализировать, как только закончите, и мне нужно подождать, пока оно не закончится, и не исчерпайте всех остальных goroutines.
Есть ли еще одна "лучшая практика" для того, как бороться с операциями блокировки третьей стороны в Go, чтобы они не исчерпывали другие горуты?
Я предполагаю, что время выполнения Go может иметь какой-то IO-цикл, встроенный в фоновый поток, чтобы "приостановить" блокировку операций goroutine до тех пор, пока они не закончили с IO. Если это действительно так, то, я думаю, было бы полезно иметь возможность строить это для новых операций блокировки.