не соображу с ходу - зачем бы это было нужно

Подрубаем что-то, через CGO, где требуется чтоб что-то вызывалось в том потоке в котором было создано. А-ля main thread для UI напрашивается как пример

ага

спасибо

1. у go есть тредпул. так что даже блокирующие операции выполняются одновременно

главное иметь ввиду один нюанс, который меня смутил примерно год назад уже. Если блокируемся на сисколе, который вызываем ручками (лично я дергал WinAPI) из множества горутин, мы вылезаем за пределы GOMAXPROCS и кол-во тредов на процесс может драматически увеличиться (процессы планировщика добавятся) и после этого до уничтожения самого процесса так и останутся висеть. Так что с блокирующими операциями при сисколах это нужно иметь ввиду

главное иметь ввиду один нюанс, который меня смутил примерно год назад уже. Если блокируемся на сисколе, который вызываем ручками (лично я дергал WinAPI) из множества горутин, мы вылезаем за пределы GOMAXPROCS и кол-во тредов на процесс может драматически увеличиться (процессы планировщика добавятся) и после этого до уничтожения самого процесса так и останутся висеть. Так что с блокирующими операциями при сисколах это нужно иметь ввиду

GOMAXPROCS никак не ограничивает количество тредов и никак с ним не связано

связано, конечно

как?

GOMAXPROCS никак не ограничивает количество тредов и никак с ним не связано

да вкурсе я. еще тогда и разобрался. как раз ты еще в слаке и отвечал на вопрос, что с этим бороться способа нет

http://blog.panic.so/images/syscall.jpg

главное иметь ввиду один нюанс, который меня смутил примерно год назад уже. Если блокируемся на сисколе, который вызываем ручками (лично я дергал WinAPI) из множества горутин, мы вылезаем за пределы GOMAXPROCS и кол-во тредов на процесс может драматически увеличиться (процессы планировщика добавятся) и после этого до уничтожения самого процесса так и останутся висеть. Так что с блокирующими операциями при сисколах это нужно иметь ввиду

А сколько можно запустить одновременно процессов??

как?

The GOMAXPROCS variable limits the number of operating system threads that can execute user-level Go code simultaneously.

то есть - тредов будет не меньше

А сколько можно запустить одновременно процессов??

если имеется ввиду тредов на процесс то от ОС зависит. в части винды - в блоге марка русиновича древний пост есть как примерно посчитать, под Linux не встречал, но за кол-вом тредов я предпочитаю следить всегда

ну да, не меньше, но верхняя граница не определена =)

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

ну да, не меньше, но верхняя граница не определена =)

прошел уже почти год, ты не встречал еще хотябы костыля, как прибить лишние процессы планировщика? Мало ли :)

если имеется ввиду тредов на процесс то от ОС зависит. в части винды - в блоге марка русиновича древний пост есть как примерно посчитать, под Linux не встречал, но за кол-вом тредов я предпочитаю следить всегда

Нет, всего можно запустить 1 процесс и в нем треды??? Например 2 ядра процессор

➜ ~ cat /proc/sys/kernel/threads-max 3095473

го - это всегда один процесс и в нем треды

го - это всегда один процесс и в нем треды

Все, с этим понятно

Нет, всего можно запустить 1 процесс и в нем треды??? Например 2 ядра процессор

в нем треды, только ОС сама аффинити на процессор треду назначает, можно ручками, но в Go я такой фигней не занимался ни разу, в других ЯП как-то игрался прибивал к ядрам прям треды

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

а потом происходит АД по КПД от таких алгоритмов, потоков дофига, а толку нифига как я это называю.

не происходит

если все эти потоки по больше части ждут ввода-вывода - все ок

в нем треды, только ОС сама аффинити на процессор треду назначает, можно ручками, но в Go я такой фигней не занимался ни разу, в других ЯП как-то игрался прибивал к ядрам прям треды

Это улучшенная версия multithreading(в которой можно запустить тредов, только сколько ядер )???

запустить можно сколько угодно

Это улучшенная версия multithreading(в которой можно запустить тредов, только сколько ядер )???

неа, не нужно путать понятие ниток, процессов ОС и реализацию внутренней кооперативной многозадачности в Go. По простому есть процесс ОС, в нем могут быть N-ниток ОС (треды), а в Go в этих нитках может исполнятся еще N-горутин конкурентно

если все эти потоки по больше части ждут ввода-вывода - все ок

ну если запустился, подождал ввода-вывода и сдох то норм, кроме потребления по памяти

конкурентно != выполняться одновременно, один процессор может выполнять только один тред

конкурентно != выполняться одновременно, один процессор может выполнять только один тред

ну а как же хитрухи типа HyperThreading и подобной технологии от AMD?) Вроде как один поток в одно время на одном ядре, а вроде как и не совсем один

а тьфу, ты про процессор - будем считать что кол-во процессоров это кол-во ядер которые отображаются в ОС для простоты и плевать на все эти технологии

а то человека запутать так можно

ну если запустился, подождал ввода-вывода и сдох то норм, кроме потребления по памяти

О, это уже понятнее, а сколько можно запустить таких ниток, в 2х ядерном процессоре с линуксом на борту?

О, это уже понятнее, а сколько можно запустить таких ниток, в 2х ядерном процессоре с линуксом на борту?

Слава выше скинул показатель потолка

cat /proc/sys/kernel/threads-max

но это тотал на ОС

если писать хочется на Go то с этим заморачиваться вовсе не нужно

запускаем много горутин и не думаем о нитках ОС вообще, за исключением тех случаев когда дергаем ручками системные вызовы из Go напрямую

запускаем много горутин и не думаем о нитках ОС вообще, за исключением тех случаев когда дергаем ручками системные вызовы из Go напрямую

И если необходимо одновременно отправить 2 файла на 2 сервера , то для этого нужно будет выделить 2 нити?

И если необходимо одновременно отправить 2 файла на 2 сервера , то для этого нужно будет выделить 2 нити?

нет

2. именно "отправить на сервер" в любом случае выполняться будет параллельно - go утилизирует асинхронный сетовой ввод-вывод

это вы прочли?

И если необходимо одновременно отправить 2 файла на 2 сервера , то для этого нужно будет выделить 2 нити?

Тебе тут уже с разных позиций описали - нить может быть вообще одна. Для всего вместе. Go сам разберется.

И если необходимо одновременно отправить 2 файла на 2 сервера , то для этого нужно будет выделить 2 нити?

одновременно не бывает. сетевой интерфейс выплевывает в порядке очереди в шнурок. если опять же по простому: сначало кусочек первого файла, потом кусочек второго, а вот прям одновременно - не бывает. Поэтому я вам предлагаю не заморачиваться с этими вещами вообще

Да всё проще. google event driven

одновременно не бывает. сетевой интерфейс выплевывает в порядке очереди в шнурок. если опять же по простому: сначало кусочек первого файла, потом кусочек второго, а вот прям одновременно - не бывает. Поэтому я вам предлагаю не заморачиваться с этими вещами вообще

Спасибо. под не одновременно подразумевается, что сначала выпоняется полная заливка одного файла , после очередь приходит ко 2му

Спасибо. под не одновременно подразумевается, что сначала выпоняется полная заливка одного файла , после очередь приходит ко 2му

теперь я понял что вы имели ввиду под понятием не одновременно. в случае Go создаем две горутины на передачу 2х файлов на 2 сервера и за Х времени они вместе уедут на 2 сервера. Не один за другим в порядке очереди, а конкурентно скажем.

теперь я понял что вы имели ввиду под понятием не одновременно. в случае Go создаем две горутины на передачу 2х файлов на 2 сервера и за Х времени они вместе уедут на 2 сервера. Не один за другим в порядке очереди, а конкурентно скажем.

Да , вот это. Спасибо за помощь.

Без обид, но ваша аватарка меня дико пугает

ну а как же хитрухи типа HyperThreading и подобной технологии от AMD?) Вроде как один поток в одно время на одном ядре, а вроде как и не совсем один

да там тоже только один процесс на процессор, просто часть вещей дублировано и кажется что логически их два

да там тоже только один процесс на процессор, просто часть вещей дублировано и кажется что логически их два

да я понимаю все это, я имел ввиду что процессору побоку такие сущности ОС как треды - выполняет поток комманд. так вот hyper-threding это фактически два потока комманд к процессору и он их граммотно переключает. А раз их 2 потока, значит система может повесить на одновременное исполнение 2 треда на 2 логических процессора, которые являются одним физическим. В итоге твое утрвеждение что один процессор может выполнять один тред не совсем верно - два треда на два логических ЦПУ которые являются одним физическим. Более точно это то, что один физический ЦПУ не может выполнять больше 1й инструкции в один момент времени. Но все это болтовня по мне так сейчас с моей стороны :)

В мою писанину можно не вникать, это перед сном меня пробило порассуждать.

процессору, кстати, современному, не совсем по боку

я не помню подробностей, но современные ос договариваются с современными процессорами о том, что у них происходит

процессору, кстати, современному, не совсем по боку

я знал что к этим моим словам можно зацепится) все верно, не побоку, но я упростил собстно и моменты опустил

там как-то хитро они делают оптимизации различные под ОС

ибо так прям чтоб я был в таких вопросах супер-компитентным я сказать не могу от слова совсем, поэтому и опустил. краем глаза где-то информацию встречал, принимаю на веру что там что-то происходит попимо моих простейших пониманий как это работает

предпочитаю не лезть в дебри, а представления свои основывать на опыте работы с простейшими цпу типа AVR контроллеров или Cortex-M3 которые где-то у меня валяются дома. Подцепил внешний тактовый генератор к AVR и больше одной инструкции за такт там не бывает, договоренностей с ОС там тоже никаких нет - все как на моем спектруме в детстве, просто и понятно. А что там внутри навороченных современных ЦПУ происходит я понятия не имею честно говоря

я бросил читать справочники по ассемблерам на i386

на i386 все было ровно так - один такт, одна (максимум) инструкция

сейчас там все иначе

сейчас там кеш, предсказатель ветвления, dma и vtx

и хинты предсказателю

я бросил читать справочники по ассемблерам на i386

была книжка у меня по 386 процессору вроде, или по 486му не помню уже, но я ее так и не осилил. спустя годы потянуло на микроконтроллеры что-то, пол года поигрался, пописал на ассемблере, Чек-ТВ мутил все (на COM выплевывается кассовый чек, накладывается контроллером на входящий видеосигнал с камеры наблюдения и на выход уже сигнал с наложенным поверх чеком, на полупрозрачном сером фоне таком), потом надоело. Хотя для разнообразия норм увлечение было.

еее скалка

Кстати насчет вот иде , какая ваша любимая для скалы ?

идея

Кстати насчет вот иде , какая ваша любимая для скалы ?

идея, либо вовсе без IDE

у sbt неплохой авторелоад

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

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

ты о чем?

Кстати насчет вот иде , какая ваша любимая для скалы ?

раз такой день сегодня: Borland Developer Studio

Пойму это минус скалы что в виме с ней не очень

Пойму это минус скалы что в виме с ней не очень

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

ты о чем?

Я говорю, скала хороший язык

Я говорю, скала хороший язык

ну вот же

пацаны, а пойдемте в чят к гоферам троллировать?

о, будем монадировать монады, да не вымонадировывать

у них там даже дженериков нет!