всем привет меня зовут а рад что вы они собрались я в своем докладе надеюсь что мы справимся но если мы запутаемся дайте знать и мы остановимся подробнее на каких-нибудь темах я сегодня расскажу из чего в целом составить программу нога чем она от например отличается от программы на языке си рассмотрим теоретическую часть о том как работает планировщик языка гоу и заглянем внутрь того как он устроен но и разберемся зачем нам все это нужно мы начнем вот такой программы кто знает на каком языке она написана правильно молодцы вот если мы скомпилируем мы получим исполняемый файл размером 8 килобайт если мы посмотрим на количество себе блюд ассемблерных инструкций через ups дамп увидим что их там всего 180 очень мало очень маленькая программа пойдем точно такую же программу на языке гоу и и скомпилированные ее размер будет 2 мегабайта в несколько раз больше и ассемблерных инструкций там 150 тысяч и иногда говорят что программ на гол статический компилируется то есть они в себя все зависимости выбирают но на самом деле на самом деле если мы скомпилируем эту программу стройном липси то размер еще почти два раза увеличится и возникает закономерный вопрос что такого крутого в программе нога что она занимает 2 мегабайта всего лишь выводит hello world на экран это на самом деле большой вопрос моего затронем поверхностно основная часть о которой мы будем говорить о the runtime runtime это окружение в котором выполняется ваша программа это главным образом тот кот которую вы не видите но который есть вашей программе и работает без вашего ведома у него входе в первую очередь планировщик о нем мы сегодня подробнее поговорим также в него входит сборщик мусора локатор памяти о них хотелось бы сегодня поговорить но скорее всего мы не успеем кроме того угоу по сравнению обширная стандартная библиотека то есть множество функций по работают по работе со строками с массивами и так далее они тоже вносят вклад свой вклад в эти два мегабайта и мной множество отладочной информации входит в этот исполняемый файл то есть информация которая не нужна для работ программа но которая нужна для отладки ну и наверное что-то еще туда входит о чем я не знаю может быть внутри каждой программы нога у находится его так сказать ее сердце планировщик который управляет работой гору then практически весь планировщика реализован вот в этом одном файле можно прям за пойти на hydra почитать и по этим корка дам вы можете прямо процесс презентация только мы очень интересно можете перейти по ссылкам и открыть зачем он вообще нужен гол немножко исторической справки в компьютерах есть операционной системы у pure zone их системах есть потоки потоки позволяют нам разбивать программы на независимой части которые выполняются конкурентно или асинхронно иногда так иногда так они стандартные работают везде но если мы хотим производительности то оказывается что они медленные и их тяжело контролировать из нашей программы поэтому разработчики языка захотели создать что-то покруче вообще в целом в языках программирования такая концепция называется зелеными трендами но ввг они назвали эти штуки go рутинами зачем мне нужны они дают контроль над выполнением задач асинхронных они позволяют экономить ресурсы если мы сравним рутины странами операционной системы to go рутина занимает меньше пару килобайт памяти по умолчанию ответ занимает где-то пару мегабайт хотя даже не факт что вам все эти пару мегабайт понадобиться при выполнении программы но таким образом 1000 thread'ов выльется в тысячу раз больше а использованной памяти чем go рутина и городе на дают нам более эффективно и переключение между задачами если мы почитаем о том как операционной система переключается между треками выяснится что это очень сложный процесс который с недавних пор тому же замедлился благодаря уязвимость найдена в процессорах intel но не будем на этом останавливаться дело в том что тренды большие сложные ага рутины по задумке автора физика должны быть простыми но это приводит нас к проблеме что мы попытаемся построить свой планировщик задач поверх планировщика задач операционной системы и как-то надо с этим жить разработчики языка предлагают нам такую концепцию они хотят они хотят дать нам только go рутины и не давать вообще 3d они даже то есть если вы начинаете программировать ногой не знаете что такое thread вы можете о них даже не узнать но при этом использовать их под капотом разработчики языка делать вид что вам доступны только go рутины и go запускать только дройдов сколько доступно вас процессор ных ядер если вы специально это не перри настраиваете и распределяют на эти thread'ы сколько угодно грудь in который уже запускает программист сейчас мы немножко поговорим о внутренностях реализации планировщика передайте нам придется изучить вот эти три термина который там постоянно используются это бред который внутри гон называется м от слова машин немножко странный выбор терминологии но суть то что машин это не какой-то компьютер или машина от red операционной системы то есть нативный thread также использовать термин и процессор и гору тина g и сейчас мы посмотрим как они все между собой взаимодействует и для чего нам вообще эти обозначения нужны если изобразить диаграмму взаимодействия между собой всех этих компонентов то мы увидим что у нас есть процессоры пи go создает их обычно по числу равному количеству ядер хотя может быть больше и меньше иногда но не важно количество тредов м обычно равно количество процессоров то есть каждый thread операционной системы привязан к процессору и когда я говорю слова типа процессоры thread это не какие-то настоящие процессоры и thread это не железка и не и не даже ресурсы операционной системы это просто структура в памяти вашей программы то есть в исходнике год прим объявлена структура пи процессор который там есть набор свойств и методов то же самое с трендом то есть это просто какие-то абстракции когда говорю процессор я не имею ввиду настоящий процесса количество гортен которые могут быть привязаны к процессору она не ограничена и у каждого процессора есть свою очередь гору then она называется ранку как мы видим только одна городе на может быть активна в текущий момент на одном процессоре то есть на том трейде в очереди может находиться неограниченных количествах и подробнее об этом можно почитать вот по этой ссылке это статья of из которой я вычел эти клёво иллюстрации тут может возникнуть вопрос зачем нам вообще отделять вот сущности m&p друг от друга потому что вроде как они связаны один к одному то есть мы понимаю что g может быть много open всегда связано и одинаково это связано с тем что thread'ы во время выполнения программы могут переходить от ног процессор к другому например таком сценарии когда вам потребовалось прочитать какой-то какой-то большой файл с диска и у вас thread делает системный вызов он просит операционную систему вернуть и этот файл и операционной системы в ответ блокирует этот трек и таким образом блокируется не только тогда рутина который понадобилось читать файл но и все остальные которые были в очереди и гоф таком случае отвязывает эти горы тено текущего процессоры отряда то есть нас процессор и очереди переезжают на другой тренд поэтому нам собственно нужно разделение m&p но в целом можно в этом не задумываться прежде чем мы пойдем дальше небольшую историческую водно о том какая вообще бывает многозадачность чтобы понять какая многозадачность используется в гол самый популярный вид многозадачности который есть в большинстве операционных систем это вытесняющая планировщик используя такой подход говорит что все программу равны он разделит ресурсы между каждой программой одинаково он выделит каждой программе одинаковое количество времени для выполнения и будет строго между ними переключаться если иск с чем это сравнить это можно сравнить с коммунизмом сравнить отнять и поделить есть также кооперативную многозадачность используется другой подход планировщик говорит что каждая программа может выполняться столько сколько и нужно и программе программы сами должны уступать друг другу место и таким образом должна бы обеспечивается гармонии эффективность как например в цен буддизме это всё клёво и об этом можно еще много чего говорить я так по поверхности прошелся но возникает вопрос какая многозадачность гол как вы думаете какой из этих двух типов первые вытесняющая до других мне не до руки ну теперь-то понятно что 2 в г используется так называемая неявная к оперативность в том смысле что мы не уступаем явным образом место гор утином но это происходит слегка-слегка под капотом гортина может уступить место другой при обращении к 2 до например при считывании файла при обращении к сети и так далее также при вызове любой функции с некоторой вероятностью произойдет переключение между городе нами опять же мы об этом не знаем но мы явно и не говорим что мы хотим уступить место наконец есть явный способ переключить планировщик на другую картину если нужно это вызов функции runtime gasket но ее использовании не особо популярна данной в основном и не требуется то есть вот эта функция это то что немножко не вписывается в куб в кооперативную парадигму но она в go есть и помимо этого рассматриваете внедрение вытесняющей многозадачности о которой мы говорили до этого первый пункт с чем это связано потому что если вы с вашей гору тени не уступаете место другим то есть не вызываете другие гору тины не обращайтесь к выводу а просто например делаете какой-то плотный цикл там вычисляете матрицы для машинного обучения или число пи с каким-нибудь миллиону знаком то у вас городе на занимает все процессор на и время и она не уступит место другим и это знать что на этом не 3 процессор больше ничего выполнить не сможет и это часто бывает проблем и поэтому в г хотят ее решить но пока что с этим связанно сложности и пока что нас только кооперативную многозадачность помимо этого чем еще руководствуется планировщик у него внутри очень простая очередь five у first in first out 1 зашел первый вышел то есть порядок запуска гору then просто обуславливается порядком их вызова также планировщик старается создавать необходимый минимум трейдов не больше трендов чем нужно не больше трендов чем у вас есть лидер также есть интересный принцип захват чужой работы это когда вы создали машины thread создали go рутины на нем потом он освободился и этот трек не будет удаляться runtime омгу он вместо этого падет и попытается украсть и других трейдов работу чтобы не простаивать зря чтобы ядра процессора не прохлаждались а работали на вашу пользу и еще один принцип который вытекает из кооперативности это не инвазивность в том смысле что он не прерывает насильно работу ваших гору then то есть если вы решили что вам нужно вычислить число пи до миллиарда знаков то ваша грудь и на будет это вычислять и никто не помешает никто и не прервет это простые принципы но у них есть и и некоторые ограничения первое ограничение связано с самим принципам очереди five а дело в том что несмотря на его простоту у него есть и недостатки кто знает какие да то есть у нас нет контроля над приоритетами задач например в операционной системе вы можете сказать что вот эту программу меня важнее этой я подниму и приоритет здесь так сделать нельзя не важность ней порядок нельзя настроить и за очередь five а кооперативную многозадачность также является следствием является причиной того что в гонит гарантий времени выполнения гору then вы не можете скажем математически доказать что эта картина выполнится хотя бы через 100 миллисекунд нет вообще никаких разговоров о гарантированном времени выполнения то есть например к по этой причине нельзя использовать в каких-нибудь критических приложениях типа самолетов звездолетов в медицинском софте и так далее кроме того картины могут перемещаться между рядами это делается для повышения эффективности использования процессор фидер но если у вас кот зависит сильно от процессор ных к шее то есть если он и интенсивно работает с оперативной памятью то переключение между треками будет вымывать эти каши и эффективность их упадет у нас от есть оговорочка право функцию land runtime lacoste red но если вы знаете зачем не спорить используйте но в целом это не дает такого контроля который мог бы дать более продвинутый планировщик на этом мы закончили теоретическую часть мы обсудили как работает планировщик в принципе но хочет узнать что там происходит на самом деле меня например интересовал вопрос давно мне просто было любопытно что общее дело ключевое слово в г и мы сейчас с вами пройдем путь не совсем короткий но надеюсь интересный который нам позволит всё разложить по полочкам и показать что никаким никакой магии слове гол нет мы будем работать с этого момента и до конца докладываться этой простой программы что она делает да да но она делает это в гору тени то есть асинхронном вы смысла в этом нет мы просто взяли простейшую программу с 1 га рутины да скорее вся она ничего не увидят хотя это не гарантирована то есть main может завершиться до и после выполнения вот этой функции но нам неважно мы просто рассмотрим простейший пример и все я сразу открою секрет что слово go и какая-то функция она приводит к выполнению вот вот этой вот этой функции runtime . не прок обратите внимание это функции с маленькой буквы а значит что до что мы напрямую вызывать не можем но как-то она все-таки называется как оно вызывается мы поймем скомпилировав гоу программу и посмотрев на ассемблер это такой промежуточный ассемблер который генерирует гол который затем превращается настоящий ассемблер но углубляться мы в это не будем просто посмотрим на то что вот оказывается 8 строка нашей программы где был написан и грм тип rental in она преобразуется в 4 вот такие строчки на сервере в первых трех подготавливаться аргументы подгадать от подготавливается стек переходу функцию и вызывается он-то мне прок и вот я думаю в регистре aix наверное находится адрес вот этой функцией которую мы хотим вызвать легко что дальше посмотрим на реализацию функций не про наверное сейчас нам откроется самый большой секрет языка гол то есть мы заходим прям туда где создается говорите на наверное мы сейчас увидим сердце самой магии там пришлось всякая подготовительная работа и вызывается функция не про к 1 ничего интересного на самом деле таких вещей об этом много в дальнейшем пропускать я просто хочу вам дать понять что все на самом деле слегка сложнее и я естественно показывать только самое важное вот собственно не прокате на ответственна за непосредственное создания картины и давайте посмотрим подробнее что здесь происходит мы раньше говорили что в ранд amiga есть структуры типа гору тина g процессор перевод здесь мы получаем текущего рутину текущей процессор создаем новую гору тину говорим ней чтобы она начала выполняться с функции f n который приходит в аргументе в нашем случае это этом тип rental and мы делаем какую-то магию вот шестая строчка на самом деле полна магия я заменил на такую простую строчку в ней мы говорим чтобы после завершения эта функция вернулась функция galaxy to any money мы погорим позже и на этом шаге создание структуры новый грудь инны закончена и вызывается функция ранки you put которая грубо говоря просто добавляет элемент в массив добавлять go рутину в массив гору then который ожидает своего полнения то с чего здесь не происходит здесь не пришлось запуска т.е. когда мы пишем голову что-то ничего не запускается на самом деле просто какая-то структура добавляется массив никакой мои вся магия происходит функций скетч функция скетчу это один раунд планировщика то есть каждый раз когда нужно выбрать какую гору тина нам запустить go вызывает функцию скетч она находится в том же файле runtime слэш прок . если упростить ход ее действий то она выглядит так сперва мы проверяем не нужна ли нам выполнить работу по сборке мусора если нужно то мы выполняем ее в первую очередь если нет то мы берем программ мы берем картину из нашей текущей очереди на нашем треке вот строка 4 и если в нашей текущей очереди на нашем треке ничего нет то мы либо пытаемся украсть картину из других трендов либо подождем потому что вдруг вдруг программист решить запустить гору чину или вдруг и нам посетить что-нибудь придет скоро и тогда мы разбудим какой-нибудь из ожидающий гортен и таким образом выбрав go рутину мы вызываем функцию execute где тут уже непосредственно выполняет переход к адресу инструкции в памяти которая должна выполнить go рутину вот на самом деле в этих восьми строчкой заключается весь смысл работы планировщика вроде бы смотреть больше нечего им я мог бы завершить на этом шаге доклад но я человек любопытный меня все равно остается вопрос как вы думаете какой вопрос их за kit я сейчас не буду в это вдаваться но в общем он выполняет переход к ассемблеру который свою очередь выполнять переход назад в runtime там все немножечко сложно но нет там нет системных вызовов кроме того если у вас если у вас на тот момент еще не трейда the tracks are дастся системным вызовом но если ты рад уже есть та система вызова не будет но суть том что мне бы хотелось узнать кто вообще вызывает функцию из кежуал потому что мы на нее посмотрели как оно вызывается мне до сих пор например непонятно и чтобы понять как это происходит как вы думаете что нам нужно сделать нужно пойти глубже кто-то по-моему это сказал спасибо мне я не хотел оставлять дикаприо и сначала хотел стали другого декабря в общем чтобы разобраться как запускается скетчу нам придется выяснить как запускается программа на гол я мог бы это время потратить на описание других тем таких как а локатор памяти или сборка мусора но я просто не мог бросить на таком интересном месте поэтому мы с вами весь доклад посвятим этому чтобы понять как запускается программа сперва вернемся я еще раз напомню что мы работаем с такой просто программы боффин тип rental and low ничего особенно и запуск программы как выясняется начинается на сервере в одном из этих файлов которые зависят от архитектуры под которым вы компилируете мы посмотрим на ассемблер под архитектуру 38 6 там нет ничего сложного первая строчка добавляет на стек адрес функции runtime . main би си это подготовка аргумента к вызову следующей функции следующая функция это runtime you prog мы ее с вами уже видели она создает новую грудь и ну какой garten она создаст какую main вот нет она создаст нас создать гору тину который будет указывать на функцию runtime и энписи не зря же мы и здесь на стек положили это это по сути подготовка аргумента к вызову не прок и как мы помним не прок сам по себе ничего не запускает он просто ложит кладет go рутину в массив собственно запуск оказывается происходит функций runtime м старт-м я напомню означает машиной thread то есть это запуск 3d функция м старт выполнять некоторую подготовительную работу вызывается кизил который мы смотрели до этого то есть оказывается вот это самое сердце программы на гол сердце планировщика оно вызывается почти сразу при запуске программы через код на ассемблере что дальше в файле runtime служб . есть функция main это еще не наша функция main это служебная функция main что она делает она выполняет всякую подготовительную работу как я уже говорил тот много строчек пропущено в частности она запускает фоне сборщик мусора и выполнять некую страну функцию main main как вы думаете что это за функция да это функция моей нашей программы там вот прям так и написано моим подчёркивание main провалиться в нее конечно же нельзя просто на этапе компиляции адрес этой функции перезаписывается адресом нашей функции main кульминацией этого действие является наконец-таки выполнения нашей программы и переход к восьмой строке голосом тип rental and мы это уже видели небольшой флешбэк я напомню что при создании функции мы указываем чтобы функция гарантированно возвращалась функцию g экзит на самом деле это шестая строка она состоит из множества строк там производится интересной манипуляции со стеком чтобы выглядело так как будто бы наша функция была вызвана функция экзит чтобы при выполнении ассемблерных инструкций re-therm red мы гарантированно вернулись газет и что же пришлось бы экзит мы там выполняем всякий опять же куча служебных действий но самое главное мы видим что вызывается скетч а вот функция джефф пьют джефф put она освобождает ресурсы только что выполнены go рутины и либо удаляет ее либо кладет на очередь из свободных грудь in который ожидает выполнении новых задач то есть мы сейчас с вами прошли весь цикл о запуска программы до вызова 1 га рутины до ее завершения и мы видим на каких шагах выполнялось функций скетч чтобы чуть-чуть улеглось главе получи давайте повторим при старте программы на ассемблере запускаются thread который выполняет ним первый раунд планировщика вызывает функцию скетч скетчу запускает функцию мейн но не нашей программы а runtime а функция main runtime запускать всякие служебных задач а затем уже запускает нашу пользовательскую функцию main и при завершении каждой грудь и на вызывается новый раунд планировщиком это выглядит немножко рекурсивно рекурсивно и идеологически так она есть но реализация такая что рику ти там на самом деле нет там не растет бесконечно стек если вам интересно можете почитать об этом подробнее в исходника самого гол из всего этого доклада мы увидели что на самом деле магии не существует что слово гол не приводит там какому-то волшебству что это обычная манипуляция обычными стандартными процессор ными инструкциями то есть ничего такого особенного создателей за какого не придумали они просто сделали удобно и слои абстракции чтобы нам было удобно программировать конкурентно кроме того мы его сейчас за такой короткий промежуток времени умудрились разобраться в том как работает планировщик которая казалось бы такая вот большая махина но vk это сделать реально думаю что во многих других компьютерных системах это было бы сложнее кроме того в начале доклады мы видели что hello world нагого занимает 2 мегабайта и хоть мы и не не успели поговорить о других компонентах runtime а но знаете что планировщик занимаетесь существенную часть место из этих двух мегабайт также планировщик как мы видели не является отдельным процессом он запускается между вызовами наших гуру тен но никак им сам по себе не мешает не останавливает их в отличие от планировка операционной системы кроме того вы наверное обратили внимание на нейминг не совсем стандартный не знаю как вас а меня бы на кадре в и например не пропустили с такими именами функций и переменных то есть код который вам показывал он абсолютно реальный он взял он взяты из исходников я ничего специально не перри миновал все выглядит так как вы видели и то что показал разумеется не является каким то финальным состоянием runtime постоянно совершенствуете завтра вы можете зайти вы сводите и увидит там уже какие-то дополнения поэтому стоит следить за релизами смотреть за выступлениями разработчиков и как я уже говорил об опустил очень много деталей что был понятно на самом деле мне самому все непонятно до конца но необязательно углубляться в самые детали просто и разумеется исходного кода намного больше чем я вам показал и наверное вы задаетесь вопросом это конечно круто но зачем все это лично для меня ответ в том чтобы удовлетворить любопытство я делаю это потому что могу потому что есть такой крутой марсоход curiosity который меня вдохновляет не то чтобы у меня вдохновляет но мне нравится что солнечную систему использует машина и следует машина с названием любопытство и я бы хотел что программисты тоже были по любопытнее потому что ну это на самом деле приводит к нашей большей эффективности к тому что мы больше знаем об окружающем мире и становимся короче помимо этого чисто практическое применение мы можем лучше понимать причиной типичных проблем например программа зависла очень такая странная ситуация но довольно типичная и знаю как работает программа изнутри мы можем легче отладить и и я не рассказал о нескольких нюансах работы gammaxx процесс докером и ограничением на процессоры но если вы чуть глубже копнете эту тему или если вы уже работали с докером и go вы уже наверное знаете об особенностях лимитов на процессор и знание планировщика поможет нам понять проблемы работы голос докером плюс мы узнали о существовании таких трендов и о таких функциях как runtime gasket и лаковый стресс и мы можем теперь их использовать первым и мы хотим использовать когда у нас какой-то плотной цикл выполняете мы хотим уступить место другой грудь и не потому что иначе мы знаем что планировщику принудительно не вытеснит текущую garten если мы не напишем gasket и используем лукой страт если хотим чтобы текущая грудь и на не уходил никуда свою отряда если нам важна использование процессор ных кощей кроме того в прикладных программах повсеместно используется принцип и планировщиков если мы разобрали как работает один из них нам гораздо легче понять другие например есть такой шаблон пул задач в том же году он часто используется когда нам прилетает разные скажем еще тебе запросы которые формируют некий задачи мы вкладываем в какую-то очередь и потом какими-то фоновыми грудь и нами разбираем это по сути такая простая реализация планировщика плюс есть такая известная программа купер нить из многие не знают по сути это тоже большой планировщик укуку верните со есть какой-то набор ограниченных ресурсов скажем это железное сервера и ему нужно распределить на них потенциально неограниченным неограниченное число задач скажем deployment of service of the galley и логика его работы очень сильно напоминает работу а планировщика то же самое касается планировщика операционной системы баз данных и так далее кроме того если мы и мы с вами задаемся вопросом чем там один язык круче другого мы придем к таким интересным вещам что многозадачность во всех языках реализовано по разному и чтобы грамотно их сравнивать то хорошо бы понимать как вообще работает скажем многозадачность go чем он отличается от роста я бы хотел наверное в это глубже углубиться но глубже погрузиться но времени на это у нас нет но по крайней мере мы теперь знаем как работает голову и если мы хотим пощупать раз стилистом скалу она уже будет проще сравниваете проще делать выбор на этом все полезные ссылочки которые я использовал при подготовке рекомендую во всем почитать и задавайте вопросы перед тем как начнем вопросы ты скажешь мне у меня есть подарочки которые хотел разыграть это 2а кружки они внесут давай ты будешь создавать одну кружку я привет специально для вас конференции москве devops кружка а другая кружка еще круче 1 эта кружка колеса тим и вопросы которые мне понравятся получат авторы вопросов получит эти кружки спасибо антон давайте поблагодарим и теперь пробу здравствуйте спасибо за доклад все было очень интересно реально мне тоже всегда интересует вот такие детальности но вопрос у меня в следующем если внутри гуру тины мы запускаем другую функцию гоу рутину она попадает в основную очередь или создается другую очередь она попадает в очередь текущего отряда то есть в основную очередь молодой человек пожалуйста микрофон сути вы сказали что а сказали что планировщик не выполняется в отдельном процессе правильно да но что происходит получается допустим если у меня на компьютере 8 процессоров меня 83 до в года по умолчанию скажем запускается где решается я так понимаю что планировщик одновременно всегда только одна функция из функции планировщика выполняется и нет получается во-первых у вас запускается не 8 трейдов по умолчанию один thread а след следующий 7 запустится по необходимости и в каждом из этих трендов будет запускаться планировщик опять же по необходимости и очередь задачу каждое утро до своя там есть нюансы там есть еще глобально очередь но мы в это не будет сдаваться основная очередь она одна на каждый thread и планировщик тоже получать 1 на свой трек вот у меня есть вопрос в самом начале когда go рутины складываются в один массив ранг you put это обычный душный append которые копируют слайс там и засовывать туда или что это такое вообще вот я туда залазил и чуть-чуть забыл там либо типа связанный список посылочки типа next сам прибавляется либо up and now что-то очень простая такое да еще у кого то образом там вот была такая штука как с вич tunngle да и вот получается она переключает на родительскую которую вызвала да да я думал об этом рассказать подробнее но время поджимает но суть в том что на каждом треде полным по умолчанию создается 1 рутинной она как бы считается главной она называется внутри их g0 на этой g0 собственно выполняется планировщик и в нее выполняется возврат и из любой другой грудь и ну вот запущенный на этом треке вот switch свечным main джей которую функций назвал на самом деле такой функции нет это просто качество кода который выполняет переход на гору тина g0 которая здесь для простоты назвал меньше вот и чем собственно заключался вопрос а после вот это switch the main g у вас вызывает саши дилер получается он сначала переходит потом вызывать 6 до планировщик вызывается из вот это основной гору тины g0 раз у вас есть очень много параллельных thread of the plot по-любому вас будет где то может случиться у тех и утечка памяти вот как вы работаете с утечки памяти как вы делаете трек вообще на практике вот я знаю витале нас использовал петров я не использовал но на практике у нас есть мониторинг всех программ которые нас работают и мы в графа не или в другом инструменте визуализации видим как как растет потребления мир наверное дополню для отслеживания как до этого рассказывал виталий встроенная утилита под названием петров через которую можно как отладить посмотреть весь стек вызовов по каждой конкретной функции можно посмотреть конкретно использование по памяти то есть и по времени и правильно написанной программе их практически не происходит но иногда встречается то есть не самого тоже приходилось использовать еще есть вопрос 20 спасибо за доклад а можно уточнить а если какая-то принципиальная разница между запуском на интеловских либо на м10 процах по отрядам принципиальный нет я примерно прошелся по осям верным файлам и они делают примерно все то же самое там отличие но в синтаксисе плюс какие-то служебные штуковины которые ну не важны по большому счету а я вот не знаю такую байку может вы расскажете не слышал добрый день спасибо за доклад и мне такой вопрос вы говорили про планировщик но вообще возможно ли этот проект планировщик самому как то при приоритет поставить свои задачи нет нельзя а вот эти функции как deformity они не входят de fer никак не влияет на работу планировщик он просто гарантирует что какой-то код выполнится до того как произойдет возврата из функции и нет тоже выполняется просто при загрузке файла при первом подключении файла но он никак не влияет на работу планировщик этот вопрос у меня такой вот работа асинхронности голой она очень сильно мне напомнил а именно работу либо на но джесси вот но если мы используем какие-то внешние связи но джейсон когда запускаем кластеры и связываю с основным процессом через леви она использует именно для соединения мазь от процесса дочернего процесса именно записи протокол мир связь между гуру гуру ти нами на каком most протоколе делается или потом просто обычный shared память используется внутри вратами конечно есть разделяемая память которая доступ который решается блокировками и так далее а вообще рекомендуется организовывать связь между городе нами через каналы про них я не говорил но я думаю любая кто программирует на гол сталкивался с каналами внутри каналов тоже мьютекс и также разделяемая память просто это скрыт от нас и на этом наверное завершим озвучь пожалуйста те самые классные вопросы за которую мы отдадим две отличнейшие кружечки мне понравился вопрос вот этого человека вот которого ты первому дал поговорить и вот следующий человек за ним который задавал два вопроса да вот да вот это окей надеюсь вам нравится devops потому что иначе началом это кружка дела пск он всем спасибо за кривой вопросы [аплодисменты]