Вопросы к зачету

Зачем тебе это? Не на что тратить свою молодую жизнь? Ну очевидно же что программирование тебе неинтересно, и заниматься ты им не будешь. Армия тебе не грозит, цепляться за ВУЗ тебе не нужно. Иди уже, займись чем-нибудь что тебя привлекает.

А кем тогда управляется их работа?

Виртуальной машиной Erlang-а, не Linux-ом.

на самом деле наоборот: не Linux-ом, а виртуальной машиной Erlang-а.

А если нет машины?

значит надо ходить пешком.

Не смешно. Лучше скажи чем отличаются горутины от файдеров.

А системный аналитик таких вещей знать не должен?

А системный аналитик таких вещей знать не должен?

А давай я задам контрвопрос: чем по-твоему занимается системный аналитик? Что является продуктом его труда?

Не смешно. Лучше скажи чем отличаются горутины от файдеров.

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

Для Erlang-а она всегда есть. Под виртуальной машиной понимается виртуализованная среда выполнения, наподобие той, что в Java, а не содержимое контейнера вроде VirtualBox.

Erlang был создан для массово-параллельной обработки, то есть для работы в большой сети. Поэтому виртуальная машина Erlang-а сделаеа распределённой, в отличие от Java и других популярных языков (которые не на платформе Erlang). Ввиду этого Linux не может управлять её обьектами.

чем по-твоему занимается системный аналитик?

системным аналитическим анализом.

Что является продуктом его труда?

аналитически проанализированный анализ.

все ж просто.

Держи пончик, можно два

Архитектура всего приложения и инфрмационные потоки в нем.

Архитектура всего приложения

А чем тогда занимается архитектор?

Архитектор без знания основ, прелестно

В Голанге тоже есть часть кода из библиотеки управление горутинами или программист сам отвечает за за передачу управления?

Что у тебя пригорает? Не хочешь не отвечай, и выйди из треда.

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

тут не нуб, тут или жир, или лиза

Твоя шаражкина контора и IT это вещи несовместимые. Не думай, что всё, что тебе там рассказывают это абсолютная истина. Зачастую бывает даже наоборот.

Что у тебя пригорает? Не хочешь не отвечай, и выйди из треда.

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

Меня-то ты послать можешь, проблемы у тебя начнутся во время собеседования. Или ты думаешь что окончив эти свои курсы прожект-менеджмента и шитья тебя все с руками отрывать будут в разнообразные конторы?

файдеры

это ещё куда? ты про fibers?

Извини, просто не будь таким противным. Нотации мне и так есть кому читать.

Green threads, файдеры, процессы в Эрланге и горутины - это одна и та же фигня?

нет, это 4 разных человека :) идея схожая, но реализация и идеология разная.

Т.е. это не планируется и не управляется самим ядром Linux как в С++ std::thread? А кем тогда управляется их работа?

ну например, смотри Аду. в языке есть встроенная конструкция task (декларация) и task body (реализация), есть task type, есть точки синхронизации через рандеву entry, accept, protected типы с совместным доступом, синхронизируемые методы в синхронизируемых типах (типа как synchronized в яве).

то есть, на уровне самого базового языка Ады (который почти Паскаль) есть отдельная конструкция которая позволяет описывать асинхронные процессы а не только синхронные алгоритмы. эту конструкцию достаточно компилятор языка Ады, например тот же GNAT, рантайм которого описан в отдельной книге переводит в отдельные процедуры (а на самом деле – сопрограммы), которые запускаются из main (которого в Аде нет, он неявный). то есть, рантайм языка когда инициализирует приложение в adainit/ деинициализирует в adafinal сам создаёт эти таски, при этом типы транслируются в записи, релизация task body может быть вложенной в пакет, тип или процедуру и автоматически сама запустится как асинхронный процесс при запуске процедуры/инициализации пакета (pragma elaborate/preellaborate в помощь для определения нужного порядка запуска с возможными циклическими зависимостями пакетов). при этом в этом (как правило, легковесном) асинхронном процессе будут точки синхронизации/ состояния конечного автомата entry, структура типа асинхронного switch из канала – accept, синхронизируемые данные типа мутексов или семафоров protected, синхронизируемые методы и общий алгоритм синхронизации – рандеву.

технически эти асинхронные процессы могут быть реализованы по-разному – и как сопрограммы/зелёные нитки полностью в рантайме, и как POSIX pthreads. в описании рантайма компилятора GNAT этому посвящены GNULL/GNARL слои многослойной архитектуры рантайма (многослойная потому что прагмами можно много чего отключить, да и альтернативный рантайм забабахать не такая уж и проблема, например отключить исключения, проверки диапазонов либо диспетчеризацию методов, если они не нужны ибо уже формально проверено через SPARK например; здесь есть профиль Ravenscar как пример формально верифицируемого через SPARK рантайма, для которого можно формально доказать максимальное время выполнения метода).

реализация task как отдельной конструкции языка Ады здесь имеет полный смысл. например, можно кросскомпилировать напрямую для исполнения на голом железе (barebones) когда даже ОС не существует. см. Ada barebones на osdev wiki, или рантайм под тот же STM или Ардуину.

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

а не платформно-специфичные вещи. опять же, кроссплатформа. например есть одна и та же программа, которую хотелось бы исполнять а) на голом железе, без ОС б) в винде с CreateThread в) в линуксе с ptheads г) с зелёными нитками.

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

в других языках – нужно страдать. то есть, реализовывать такие вещи самому. конечно есть библиотеки, ну и std::thread уже в современном появился. но интеграция таких библиотек или стандартной реализации ещё оставляет желать лучшего.

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

если не нравится ада, возьми тот же Go и его рантайм. в нём реализованы а) ad-hoc интерфейсы б) сборщик мусора в рантайме в) goroutines г)каналы для синхронизации процессов Хоара через goroutines для concurency, а не многопоточности.

или Plan9 с его сишной библиотекой. или Inferno и Limbo, где корутины встроены в VM Limbo, Dis.

в общем и целом рантаймы этих языков устроены почти одинаково.

Erlang немного отличается, в основном семантикой let it fail (опять же, сравни panic в Go).

если за Rust, то там тоже есть паника и основная разница в том, что корутины были раньше в стандартной библиотеке, потом их выкинули в отдельную. ну и они вроде менее зелёные стали. ну и сборщик мусора по идее не нужен с линейными типами и семантикой владения верифицирумыми. ну и вырвиглазный синтаксис для всего этого, куда же без него. и моноиды вместо исключений. и ООП трейтами а не «авраам родил исака и т.п.»

Попробуй, для разнообразия, покопать задачу. Насколько помню, описание практически всех этих планировщиков есть в интернете. Проведи исследование, сравни, подумай. Думать - твоя работа.

А кем тогда управляется их работа?

самим приложением, которое выполняется на голом железе, его рантаймом. или рантаймом ОС если это встроенная ОС.

например, для микроконтроллера PIC 16F84 была ОС, которая занимала примерно сотню байт. планировщик там был встроеный, реализация на основе сопрограмм.

нечто похожее нетрудно изобразить и на основе конечных автоматов, SWITCH-технологии и прочих акторов. например тот же nginx внутри устроен на основе конечных автоматов, в результате ему не нужно столько ресурсов, сколько форкающийся апач просит (хотя современный апач уже не совсем тупо форкающийся, опять же сервера приложений как рантайм с таким планировщиком простыми средствами).

Я тебе не нотации читаю, а задаю конкретный технический вопрос: чем аналитик отличается от архитектора. У меня есть серьезное подозрение что ты этой разницы не понимаешь. Мне кажется, что в понимании этой разницы ты должна быть заинтересована больше всех. Мне, как ты понимаешь, абсолютно все равно какой там у тебя уровень знаний. Как верно было сказано на башорге: «чем хуже вы учитесь, и чем более говенными специалистами становитесь, тем ценнее я становлюсь для рынка, т.к. конкуренции вы мне точно не составите»

или исходники BuguRTOS почитай – вдумчиво, вслух, с выражением.

раскрашивая избранные места разноцветными маркерами. рисуя sequence диаграммы по ходу дела.

чем аналитик отличается от архитектора

анализом или синтезом. синтез, конечно сложнее.

А по-моему, очень даже смешно. Хы )

Green threads, файдеры, процессы в Эрланге и горутины - это одна и та же фигня?

Это некорректно поставленный вопрос.

Т.е. это не планируется и не управляется самим ядром Linux как в С++ std::thread? А кем тогда управляется их работа?

Например, ими самими. Через отдачу управления другому потоку явно (yield) или неявно (в точках ожидания событий, IO например). Или планировщиком в юзерспейсе, что позволяет вытесняющую многозадачность без участия ядра. Даже в википедии про это достаточно написано.

файдеры

Fiber?

В некотором смысле одно и то же, но есть тонкости. Управлять может планировщик / ивентлуп, а могут сами корутины.

это бесполезное существо как и менегер проекта

Erlang был создан для массово-параллельной обработки, то есть для работы в большой сети

Насколько я помню, Joe сам утверждал, что Erlang был создан для fault-tolerancy, а concurrency и прочие плюшки — это лишь побочные эффекты выбранной им реализации.

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

У эрланга достаточно слабая параллелизация

Я говорил про concurrency.

менегер от слова menagerie? то есть, «зверинец»?

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

Как без участия ядра будет прерываться текущее выполнение и вызываться планировщик? Да, можно что-то изобразить, если есть специальная железка с таймером, на который через какой-нибудь uio можно повесить обработчик прерывания, но интересует более общий случай. Можно даже ссылкой на википедию.

Как без участия ядра будет прерываться текущее выполнение и вызываться планировщик?

Да хоть сигналом. Сходу нашёл на GH две реализации.

если есть специальная железка с таймером

Што? Какое нахрен отношение железка имеет к юзерспейсу?

Не на что тратить свою молодую жизнь?

Армия тебе не грозит

Смелые гипотезы, бро.

без участия ядра

Да хоть сигналом

Понятно.

Што? Какое нахрен отношение железка имеет к юзерспейсу?

В том-то и дело, что, как правило, никакого. Но без участия ядра единственное, что может прервать процесс - специализированная железка.

Про монады лучше преподу расскажи.

систематически а-наливает — главная рука застолья.

Про какие?

Green threads, файдеры, процессы в Эрланге и горутины - это одна и та же фигня?

Это всё не нужно. Вот что действительно нужно, так это аджайл и скрам.

Про монады в принципе. Там можно только по функторам на час задвинуть речь.

Армия тебе не грозит

С чего бы?

https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcSo5QRX39I_-jKRuT-eBJvVo7fqsCfpuyQL_G7I07NIUNDiIMWt&s

А ничего смешного тут и нет.