go-процедуры не имеют имен; они просто анонимные работники. Они не предоставляют программисту уникальный идентификатор, имя или структуру данных. Некоторые люди удивлены этим, ожидая, что go оператор, будет возвращать некоторый элемент, который можно будет использовать для доступа и контроля go-процедуры позже.
Основная причина, по которой go-процедуры (goroutines) являются анонимными, заключается в том, что весь язык Go доступен при программировании конкурентного кода. Напротив, модели использования, которые появляются, когда потоки и go-процедуры имеют имена, могут ограничивать то, что может делать библиотека, использующая их.
Вот иллюстрация трудностей. Однажды кто-то называет go-процедуру и строит модель вокруг нее, эта go-процедура становится особенной, и возникает искушение связать все вычисления с этой go-процедурой, игнорируя возможность использования нескольких, возможно, совместно используемых go-процедур для обработки. Если пакет net/http связан каждым запросом с go-процедурой, клиенты не смогут использовать больше go-процедур при обслуживании запроса.
Более того, опыт работы с библиотеками, например, для графических систем, которые требуют, чтобы вся обработка происходила в «главном потоке» показал, насколько неловким и ограничивающим может быть такой подход, когда развернут на конкурентном языке. Само существование специального потока или go-процедуры заставляет программиста искажать программу, чтобы избежать сбоев и других проблем, вызванных непреднамеренной работой не в том потоке.
Для тех случаев, когда определенная go-процедура действительно особенная, язык предоставляет такие преимущества, как каналы, которые могут быть использованы гибкими способами для взаимодействия с такой go-процедурой.
Читайте также:
Комментариев нет:
Отправить комментарий