Мне кажется это через день тут разжовывают )

ну - часто, да

я понял

это из runitme/proc.go

➜ /usr/local/go/src/runtime cat proc.go |rg machine // M - worker thread, or machine. // P - processor, a resource that is required to execute Go code. // M must have an associated P to execute Go code, however it can be // blocked or in a syscall w/o an associated P.

> | rg > го чат Тонко.

Горутины: всё, что вы хотели знать, но боялись спросить / Хабр https://m.habr.com/post/141853/

модет я один читаю хабр go?

➜ /usr/local/go/src/runtime cat proc.go |rg machine // M - worker thread, or machine. // P - processor, a resource that is required to execute Go code. // M must have an associated P to execute Go code, however it can be // blocked or in a syscall w/o an associated P.

забавно, что это единственное упоминание machine, дальше идут threads (кроме multicore machine, но это про другое)

➜ /usr/local/go/src/runtime cat proc.go |rg machine // M - worker thread, or machine. // P - processor, a resource that is required to execute Go code. // M must have an associated P to execute Go code, however it can be // blocked or in a syscall w/o an associated P.

да

короче

тебя обманули, никто не использует термин "Машина"

// The main concepts are: // G - goroutine. // M - worker thread, or machine. // P - processor, a resource that is required to execute Go code. // M must have an associated P to execute Go code, however it can be // blocked or in a syscall w/o an associated P.

тебя обманули, никто не использует термин "Машина"

это типичные потоки, они же треды (они же системные потоки)

и машинами их не называет вообще никто

вот теперь давайте вернемся к вопросу

как происходит разлочка канала

а какая разница?

то есть - почитайте исходники, если это почему-то важно

переделанный вопрос внимание! вопрос знатокам. если одна горутина успешно прочитала из канала и продолжила выполнение на потоке 1, означает ли это, что горутина-отправитель тоже продолжает исполняться на потоке 2, т.е. не находится в очереди Px (хз что это) ? Канал небуферизован.

означает

, если не стоит GOMAXPROCS=1

если стоит, то она будет работать до того момента, пока не произойдёт переключение контекста

переделанный вопрос внимание! вопрос знатокам. если одна горутина успешно прочитала из канала и продолжила выполнение на потоке 1, означает ли это, что горутина-отправитель тоже продолжает исполняться на потоке 2, т.е. не находится в очереди Px (хз что это) ? Канал небуферизован.

это абстрактное упрощение, но тоже пойдет

переключение можежт произойти в ряде случаев, которые есть в спеке

это абстрактное упрощение, но тоже пойдет

это твой же вопрос

только "машина" заменена на "поток"

переделанный вопрос внимание! вопрос знатокам. если одна горутина успешно прочитала из канала и продолжила выполнение на потоке 1, означает ли это, что горутина-отправитель тоже продолжает исполняться на потоке 2, т.е. не находится в очереди Px (хз что это) ? Канал небуферизован.

Ну в очереди на исполнение может стоять ещё много рутин, разве нет?

при том, как устроен в go шедулер - они стоят там все :)

потому что те, которые не стоят - исполняются

горутины раскидываются по потокам (магическим образом), поэтому одновременно (прям одновременно) может исполнятся столько рутин, сколько у тебя возможных потоком на пеке

Ну там же много очередей.

И может шедулер предпочесть уже загруженный контекст, вместо переключения на новый?

тут надо бы понимать, что такое "исполняется"

горутины раскидываются по потокам (магическим образом), поэтому одновременно (прям одновременно) может исполнятся столько рутин, сколько у тебя возможных потоком на пеке

если они имеют доступ к общей памяти, то это гонка данных/состояние гонки, и это решается через мьютексы

и еще тот же вопрос но для неблокированных операций через select default

И может шедулер предпочесть уже загруженный контекст, вместо переключения на новый?

у шедулера имеется там очередь событий, и управление горутины получат в порядке определяемом событиями

select это же просто спин лок с рандомным выбором действия

тут надо бы понимать, что такое "исполняется"

так вот - горутина, заблокировавшаяся на сисколе (вместе с тредом) - она исполняется с точки зрения шедулера.

так вот - горутина, заблокировавшаяся на сисколе (вместе с тредом) - она исполняется с точки зрения шедулера.

А разве сискол тоже не вызывают смену контекста?

(по-моему вызывает)

а какая разница?

есть как минимум два последствия: 1. нужно, чтобы очередь горутин на P1 совпала с P2 по позиции этих двух горутин, чтобы их одновременно посадить на машины, 2. таким образом можно обеспечить гарантированное рараллельное исполнение кода

а как это может произойти? тред-то заблочен. можно снять с него горутину, но зачем?

есть как минимум два последствия: 1. нужно, чтобы очередь горутин на P1 совпала с P2 по позиции этих двух горутин, чтобы их одновременно посадить на машины, 2. таким образом можно обеспечить гарантированное рараллельное исполнение кода

вы что-то успели намерять уже, или это чистая теория?

теооия

потому и спросил

тогда не надо этим заниматься

смысла 0

а как это может произойти? тред-то заблочен. можно снять с него горутину, но зачем?

ну например, если мы сделаем 2 рутины, крутящиеся в цикле, и поставим GOMAXPROCS=1, то будет выполняться только одна

а если добавим в неё fmt.Println (т.е. сискол), то скедулер переключится на вторую

ну например, если мы сделаем 2 рутины, крутящиеся в цикле, и поставим GOMAXPROCS=1, то будет выполняться только одна

шедулер, если все треды заблочены на сисколах, просто расширит пул

с GOMAXPROCS=1?

ага

еще это иеет значение такое: стоит ли делать сильносвязанные горутины небуферизированными каналами, и если да, то до какого предела и какие последствия будут для остальных горутин, если мы имеем например всего 4 ядра (для примера)

ага

да ладно?

ага

колом программе встать никто не позволит

подожди

так речь не про это, а про контекст свитч как таковой

https://morsmachine.dk/go-scheduler

Судя по этой штуке шедулер может отдельный поток под сискол поднять.

да он просто системе отдаст и всё, не? UPD: не.

> The syscalling thread will hold on to the goroutine that made the syscall since it's technically still executing, albeit blocked in the OS.

в общем, обожаю горутины

ERROR: S client not available

так вот - горутина, заблокировавшаяся на сисколе (вместе с тредом) - она исполняется с точки зрения шедулера.

перед вызовом сисколов есть какой то код, который горутину кладет в очередь к P и снимант ее с M, разве нет?

Не всегда

там даже для cgo что то такое есть

я по диагонали смотрел, могу ошибиться

Если на каждый маленький сискол переключаться, можно и не успеть всё сделать

смысла 0

еще вот сценарий зависона может быть: связываем две горутины небуф. каналом, одна пишет, вторая читает, далее обе делают что то без возможности скинуть в очередь, например, что то считают. тогда если у нас gomaxprocs=2, два ядра, и две машины, то эти обе горутины будут исполняться одновременно, олна на M1, вторая на M2, и все залочится. это реально?

Как это

Одновременно и с каналом работать и считать?

это если теория верна

что две горутины - читающая и пишущая, для успешного продолдения рабоиы обязаны одновременно быть на двух разных машинах

Одновременно и с каналом работать и считать?

сначала с каналом, затем for{}

что две горутины - читающая и пишущая, для успешного продолдения рабоиы обязаны одновременно быть на двух разных машинах

Не обязаны. С чего бы?

Нельзя же одновременно в канал писать/читать и считать

В рамках одной горутины

Не относится к вопросу, но в го одна горутина может писать напрямую в стек другой, если та ждет на чтении из канала

Кажется это единственное место такое

Недавно начал писать на го! Написал своеобразное апи для одного сервиса. Сейчас хочу написать апи для одного сайта (только апи, фронтенд будет на js'е) Хочется подойти более-менее основательно, поэтому хотел бы попросить совета какие инструменты лучше использовать, чтобы минимизировать написание кода для всяких шаблонных вещей типа структур таблиц в БД, структур для json'а и прочих вещей. Пока идеологически планируется примерно следующая архитектура - есть точка входа (возможно несколько, но пока будет использоваться одна). В зависимости от переданных данных запрос перенаправляется в один из модулей через gRPC (тут тоже хотелось бы какую-то подсказку, примеры по использованию, желательно в рамках какой-нибудь IDE - я использую goland от jetbrains). В большинстве своём интересуют вопросы связанные с приспособлениями для работы с gRPC, генерации структур по таблицам БД и json, и возможно по работе с easyjson (пытался сгенерить с помощью него структуры, но тоже как-то неудачно, а говорят производительности он неплохо прибавляет по сравнению со встроенным)

Keep it simple

Начинай с простых вещей, со стандартной библиотеки

Пусть даже код будет более talkative

Всё равно перепишешь ещё раз пять

ну я написал достаточно большое апи, порядка 4-5 тысяч строк и именно базовые вещи, да и +- как работает всё понятно интересно именно разобраться как 1)правильно писать такие апи (слышал что можно описывать апи в некотором формате, а на его основе будет генериться серверная часть и допустим клиентская) 2)как работать с grpc (хотелось бы какие-то практические примеры использования в ide) 3)со структурами понятно -просто уменьшение времени написания шаблонного кода 4)ну easyjson вишенка на торте, но етсь подозрения, что ключик к нему там же где и к grpc

Если у вас grpc, то вы апи описываете в протобафе

Это мало связано с ide

Привет ребята , кто может автобота создать в телеге ?

Привет ребята , кто может автобота создать в телеге ?

мегатрон?)

мегатрон?)

В телеге который продаёт

В телеге который продаёт

бюджет 100 рублей?)

Я б за такое бан дал

Я б за такое бан дал

надеюсь не мне)

надеюсь не мне)

И тебе за компанию