Но, вернемся к нашим запрещающим книги баранам. Плодом их трудов явилась ситуация, когда я прочитал всю эту фантастику «ближнего прицела» уже в нулевые, по мере появления книг в сети.
Странно мне это. Я Немцова, Адамова и т.п. читал в свое время (вторая половина 70-х) в обычной городской библиотеке (хотя и не новой, в неё ещё мой отец ходил). Правда — исключительно в читальном зале: на дом такие книжки повышенного спроса — не только 50-х, но и современные на тот момент детективы и фантастика — не выдавались, чисто чтобы им ноги не приделали.
А 3-томник Казанцева, купленый каким-то образом родителями в те же 70-е, у меня до сих пор в шкафу валяется.
Статья получилась интересная. Но, к сожалению, она в качестве источника информации имеет серьезные недостатки.
Прежде всего, в ней не отражена недостаточная надежность социологических данных, на которых основаны её выводы. В частности, исследование Deloitte, на отчет по которому ссылаются в статье как на источник данных о сравнительной популярности и уровне доверия для Интернета и других СМИ, проводилось путем опроса в Интернете(sic!), о чем Deloitte честно пишет —
Метод сбора данных
Для реализации поставленных выше задач мы использовали количественный метод сбора данных – онлайн‑опрос по квотированной выборке, соответствующей социально-демографическому портрету населения России (1 600 респондентов).
— и не забывает сделать оговорку о том, что это ведет к неточности результатов:
Ограничения исследования
Принимая во внимание текущий уровень проникновения Интернета среди россиян, происходит смещение выборки в сторону Интернет‑пользователей.
Более того в отчете, к сожалению, не указан способ привлечения пользователей Интернета к опросу. А это, на мой взгляд, существенно, т.к. при пассивном привлечении путем размещения на каких-либо ресурсах (т.е. в нем участвовали те, кто его смогли увидеть, а не те, кого заранее выбрали организаторы опроса) активные пользователи Интернета имеют больший шанс поучаствовать в опросе, чем те, кто пользуется Интернетом от случая к случаю — что ещё больше смещает выборку и делает результат ещё менее надежным. Но, к сожалению, автор статьи не сделал оговорку о том, что что результаты Deloitte могут иметь систематическую ошибку, приводящую к завышению важности Интернета как медиаканала.
Далее, вывод из исследования Deloitte о том, что
Интернет безоговорочно стал основным источником информации… по уровню доверия (42%)
приводится, к сожалению, по отношению ко всему Интернету чохом, без указания на то, что такой уровень доверия имеет лишь категория «Интернет (новостные, аналитические, официальные сайты)». Но — отнюдь не категория «Интернет (социальные сети и блоги)», уровень доверия для которой (13%) меньше, чем для телвидения (28%) и, хотя и повысился по сравнению с прошлым годом, всё ещё находится ниже достигнутого в 2015 году уровня (15%). А поскольку в статье далее подробно обсуждаются только социальные сети и блоги, но не новостные и официальные сайты, то в результате прочтения статьи может возникнуть ложное впечатление, что блоги/социальные сети пользуются большим доверием, чем телевидение. К сожалению, автор статьи ничего не сделал, чтобы не допустить этого, ложного, впечатления у читателей.
Указанные недостатки, на мой взгляд, существенно снижают ценность статьи как источника информации для читателей, не имеющих возможности или желания подробно анализировать источники, использованные в статье.
Ну, так оно работает (или работало) не только у меня в голове, но ещё и в голове у тех, кто специально изучал реальную экономику и написал про это научные труды (я имею в виду Адама Смита, Рикардо, Парето и пр.), а потом — у тех, кто на основе этих трудов написал учебники, которые другие люди изучали и пользу из этого извлекли. Что IMHO свидетельствует о том, что в голове у тех, кто изучал и кто писал учебники всё было отражено адекватно (кстати, поскольку я — не экономист, то я не претендую, что излагаю экономическую науку без ошибок, но, надеюсь, в главном я прав). Так вот, на поверхности рынка видно бурление стихии, а под капотом у него работают теоремы о благосостоянии, ведущие к такой оптимизации эффективности общественного производства, которая другими методами пока что недостижима.
Что касается вашего возражения, то оно возражением по сути не является. Всё правильно: на рынок выходят покупатели и продавцы не только со своими продуктами и спросом на них, но и со своими причудами. А уж механизм конкуренции оценивает, насколько эти причуды полезны для общества. И результаты оценки могут быть весьма неожиданными — например, появляется рынок «крафтовых» продуктов. Или — Hi End аудиотехники с его «теплым ламповым звуком».
Сказать заранее, что именно решит рынок, трудно, а ошибиться — легко. Поэтому вы имеете полное право выбирать, как именно делать свою работу — до тех пор, пока условия на рынке это вам позволяют. Но если не позволяют, то единственный полезный подход — не ныть, а смириться и зарабатывать деньги.
PS То, что программисты могут сейчас выбирать, на кого работать — это верно. Но не факт, что это будет верно в будущем — потому что, например, это было совсем неверно лет 25 назад на территории СНГ.
А что, разве в Postgres нет штатной утилиты для восстановления целостности БД с потерей информации, такой как gfix в Inetrbase и его потомках (или DBCC CHECKDB в MS SQL, или eseutil /p для БД на Extensible Storage Engine от MS — Exchange и системные БД компонентов Windows Server)? Упущение, однако, IMHO.
Ибо в Interbase в некие древние времена (ещё когда Delphi было модным средством разработки приложений) мне как-то пришлось воспользоваться gfix на боевой БД — и это было сильно проще, чем описанные в статье мучения.
Вряд ли кто-то из программистов в здравом уме прямо так и думает о себе: «Я — элита»
Ну, не скажите: тут недавно как раз всплыла ссылка на типовой креатив интеллигента советского разлива с Прекрасного.it на тему «я — элита, а вокруг меня — быдло», причем — в контексте того, что автору комментария она глаза на мир открыла.
IMHO он, наоборот, задумывается слишком много: ищет какой-то великий смысл в своей работе, кроме простого экономического — зарабатывания денег.
То есть, его почему-то не устраивает простой подход, что деньги он получает, продавая свой труд на рынке рабочей силы покупателям, они же — предприниматели. Что он на работе не самовыражается, не творит шедевры, а является винтиком в народнохозяйственном (он же — экономический) механизме. И польза его деятельности для народного хозяйства (то есть, для остальных людей) измеряется исключительно получаемой зарплатой. Потому что именно так работает рыночный механизм регулирования экономики — наилучший из доступных человечеству механизмов, заменить который на что-то, более эстетическое и рационально устроенное и, при этом, не менее эффективное, пока что не получается.
Впрочем, поскольку мы живем в свободном обществе, никто не мешает автору того поста, как и другим желающим странного, заниматься художественным программированием за свой счет. Более того, если эта деятельность вдруг окажется достаточно нужной для общества, то и материальное вознаграждение за неё не заставит себя ждать.
Как-то так.
В данном случае вы заблуждаетесь. Reactor pattern(та самая ссылка, которая в статье) — это именно общий принцип, «паттерн»(шаблон проектирования, если по-русски), «повторяемая архитектурная конструкция, представляющая собой решение проблемы»(из Википедии).
А частью программы (реализацией этого общего принципа), причем, в данном случае — коренной, составляющей основную её логику, являются struct reactor и работающие с ними функции в программе автора.
В более сложных программах разные её части могут реализовывать разные общие принципы. Например, в одной и той же программе для современных (в смысле не 3.x) версий Windows может быть, например, как графическая часть на основе событийно-ориентированного программирования, так и логика обработки подключений клиентов по сети с использованием Winsock, использующая другую парадигму. Например — выделенные потоки для каждого клиента, такие программы можно легко и просто клепать в Delphi: там графические и сетевые компоненты для накидывания на форму берутся из одной кучи.
Модифицированная версия выделяет фиксированное число потоков (thread pool), тем самым не позволяя системе аварийно прекратить исполнение, но вместе с тем привносит новую проблему: если в данный момент времени пул потоков блокируют продолжительные операции чтения, то другие сокеты, которые уже в состоянии принять данные, не смогут этого сделать.
Тут есть ещё одна проблема (или другая сторона той же проблемы): число потоков для такой архитектуры подобрать трудно. Если потоков будет слишком мало, то пул часто будет истощаться из-за того, что они ожидают завершения блокирующих операций ввода/вывода. Если много, то избыточное число активных потоков приведет к потерям на частое переключение между ними.
Для эффективной реализации парадигмы пула потоков нужен механизм в ОС, который, даже при наличии задач в очереди обработки, реализует запуск на обработку только ограниченного (например, равного числу ядер в системе) числа активных потоков, меньшего полного числа потоков в пуле. Такой механизм должен отслеживать число активных (не заблокированных на вводе/выводе) потоков, и если их становится мало, запукать обработку в дополнительных потоках из пула. При наличии такого механизма истощение пула потоков становится менее вероятным, при том что потери на конкуренцию между активными потоками остаются на приемлемом уровне, т.к. число активных потоков привышает желательное только на короткое время.
В Windows такой механизм — IO сompletion port — есть уже довольно давно. Но вот в часто используемом для создания веб-серверов Linux с таким механизмом, насколько мне известно(если я ошибаюсь — просьба поправить), есть (или были до недавнего времени) проблемы, а потому подход с пулом потоков в Linux работает (или работал) сильно хуже событийно-ориентированного неблокирующего подхода (как в этой статье).
PS А ещё меня в очередной раз умилил пример «проектирования на основе паттернов» (наиболее заметной частью которого IMHO является назначение красивых имен давно известным приемам программирования) из названия статьи: в данном случае красивым словом Реактор(Reactor) названо давно и хорошо известное (в частности, GUI Windows реализован именно в этой парадигме) событийно-ориентированное программирование. С одной стороны, конечно, не могу отрицать полезность паттернов — красивые имена повзоляют легче запоминать приемы (действительно полезные), но вот с другой стороны не умеющему «в паттерны» трудно сразу понять, что речь на самом деле идет о чем-то хорошо ему знакомом.
Там нет «нескольких VM». Да, там происходит некоторая виртуализация DOS, но это не OS/2 и даже не Windows.
«Некоторая виртуализация» заключалась в том, что эти копии DOS могли работать независимо дург от друга и параллельно, в режиме вытесняющей многозадачности. А то, что они использовали один и тот же код ядра, то это и в других гипервизорах встречалось: например, в VM/SP, где все VM с одной и той же хранимой системой (например, CMS) использовали один и тот же код ядра.
DESQView может работать на 80286 и даже 8086! Какие, к бесу, виртуальные машины???
Да, тут требуется уточнение: речь была конкретно о версии Desqview 386 (с которой я некогда реально работал).
Про CEMM от Compaq, вы, я так полагаю, не в курсе?
В курсе: как вы заметили, я отнюдь не утверждал, что Quaterdeck научилась это делать первая.
Тут уже начинается мухлёж с терминологией.
Факт состоит в том, что Desqview (равно как и Win3.x Extended mode) выполнял фукцию управляющего ПО, работавшего на уровне ниже ОС (DOS в конкретном случае), с более высокими привилегиями, и определявшего, что именно из аппаратуры и прерываний доступно вышележащей ОС — что обычно как раз и называется в наше время словом «гипервизор» (да, раньше такого слова не было, в VM/SP, к примеру, этот компонент именовался незатейливо: Control Program).
И даже Windows 3.x, научившись использовать VM8086 напрямую… Всё равно делала лишь клоны (откуда и проблемы совместимости с DR-DOS). А вот Windows-95 — там уже был гипервизор…
Windows 95 от Windows 3.x Extended Mode в этом плане архитектурно отличалась мало: и WIN386.EXE из Win3.x, и VMM32.VXD выполняли примерно одни и те же функции компонента Virtual Machine Manager: управление вытесняющей многозадачностью для VM (выполняющих DOS и системной, выпоняющей Windows), обработку прерываний, управление памятью… Подробности (которые сейчас представляют, разве что чисто исторический интерес) можно прочесть, например, в старой книге Шульмана «Неофициальная Windows 95». Ну, а режим совместимости — он был поблажкой именно ради совместимости с TSR(резидентными программами для DOS), работающим с обращениями к файловой системе и диску (которые были как полезные, ради которых эта проверка делалалсь, так и наоборот — то есть вирусы). А так, в принципе, Windows могла его и не включать, и работать с файловой системой, не используя код DOS (и Win 3.11 тоже могла, называлось это 32BFA, VxD под это в ней был, только им часто не пользовались, потому как в нем как раз упомянутого режима совместимости не было)
С вашего поволения, немного развею туман веков над этим вопросом.
Компания называлась Quarterdeck (полностью — Quarterdeck Office Systems), выпущенный ей продукт для виртуализации DOS (в котором можно было запускать несколько DOS VM в режиме виртуализации реального режима — V86) — DESQView.
Спецификация EMS к виртуальнм машинам прямого отношения не имела: она описывала, как можно отображать в доступное адресное пространство объем памяти, больший, чем пресловутые 640К(в реальности — 1М, т.к. оставшиеся 384К были зарезервированы под адресное пространство для ПЗУ и памяти, используемой переферийными устройствами) — через специально отводимое перемещаемое по этой большей памяти «окно». Такие решения по расширеню адресуемой памяти в истории развития вычислительной техники возникали неоднократно (кто был первый — даже не знаю). К примеру, когда развитие ОС для x86 уперлось в ограничение 32бит адреса, то в Windows Server появилось аналогичная по своей сути спецификация доступа к памяти свыше 4ГБ — AWS.
В случае EMS изначально предполагалось, что управление отображением будет реализовано специальной аппаратурой (размещенной вместе с дополнительной памятью на плате расширения или выполненной внутри чипсета). Однако уже упомянутая Quaterdeck научилась использовать вместо этой аппаратуры появившийся в 80386 режим виртуализации V86. Для этого она выпустила драйвер QEMM-386. Который тоже отчасти был чем-то вроде «одноместного гипервизора»: DOS после инициализации этого драйвера работала не в реальном, а в V86 режиме процессора, но — с прямым отображением почти всей памяти (виртуальные адреса были равны реальным) — кроме области окна, в которую этот драйвер отображал в соотвествии со спецификацией EMS имеющуюся в системе оперативную память, находящуюся над границей 640К.
PS А ещё, кстати, гипервизором для DOS была и Windows(в расширенном режиме) — в ней DOS-окна запускались как раз в режиме V86.
В статье есть досадный (IMHO) пробел: полностью отсутствует упоминание об аппаратной виртуализации реального режима в процессоре 80386 и его потомках и клонах (режим V86) и о его использовании для создания виртуальных DOS-машин в Windows 3.x и 9x/ME (а также — в уже упомянутой DesqView и других ОС для ПК).
С одной стороны анемичная модель и дешёвое решение — это хорошо, ведь у начинающих программистов появиться понимание нового измерения в программировании — бизнес-объекты. Однако, занимая подобную позицию вы делаете плохо себе же. Нанимая каждый раз более слабого программиста, который может делать примерно то же самое что и вы копипастой, разве у вас найдётся аргумент для бизнеса поискать более сильного сотрудника?
И в следующий раз когда вы подумаете куда идти на интервью, тщательно подумайте что вы, выбираете — компанию нещадно перепродающую ваши скилы, или кому они действительно нужны для решения конкретных задач. В ваших силах помочь такой компании быть лучше, попробовать при этом соразмерные методики и подходы, сформировать сплочённый коллектив, выполнить свою миссию программиста.
Я правильно понял по этим фразам, что вы рассматриваете Domain Driven Design не как средство решения конкретных проблем бизнеса, способное повысить его эффективность, а как средство защиты программистами, его освоившими, своих привилегий (в виде высокой зарплаты и т.п.)?
Если я понял неправильно, то поясните, пожалуйста, что вы на самом деле имели в виду.
Совершенно логично, что вредят. Потому что ваши материальные интересы полностью противоположны интересам работодателя: работодателю нужно, чтобы вы работали побольше за меньшую плату, а вам — наоборот. Поэтому все эти меры «морального стимулирования» (как это называли в СССР) — они проводятся в интересах работодателя, то есть, в случае успеха — дожны навредить вашим интересам.
Эта история свидетельствует не более(и не менее), чем о деградации системы советской пропаганды. Потому как задача справится с нежелательным совпадением имен раньше решалась куда успешнее, причем — при значительно худших исходных условиях.
Хотите примеров — их есть у меня.
Для многих наших современников словосочетание «Фома неверующий», так же, как и 100 лет назад вызывает в памяти совершенно конкретную фигуру — апостола Фому. Но вот для совеских детей это было совсем не так: у них это словосочетание ассоциировалось совсем с другой историей: «В одном переулке стояли дома/В одном из домов жил упрямый Фома» — было такое, весьма забавное и весьма поучительное стихотворение одного из советских поэтов. То есть, у советской пропаганды более ранних времен вполне получалось заставить забыть имя библейского персонажа. Библейского! Из глубины веков!
А тут — имен каких-то диссидентов, которых почти никто в СССР и не знал, испугались. И ведь при правильном подходе, никто бы и не узнал (почти, в пределах статистической погрешности, которую органы могут и подчистить, если что), что это — не имена вымышленных героев из фантастики, а неких реальных людей.
Деградация — налицо.
Обычно всякую хорошую идею кто-нибудь, когда-нибудь и где-нибудь реализовывал.
В частности это касается и идеи возобновления выполнения выполнения как способа обработки исключений.
Первая известная мне реализация появилась в продукте, с которым почти все наверняка сталкивались — в API ядра Windows NT (которая является предшественником всех современных версий Windows) и основанном на нем API Win32. Называется она Structured Exception Handling (SEH), существует с самой первой версии WinNT и широко используется самим ядром. В целом SEH аналогична по функциональности другим системам обработки исключений, но ней есть дополнительный вариант — продолжить выполнение кода после его прерывания: для этого обработчик исключения должен вернуть значение EXCEPTION_CONTINUE_EXECUTION.
Это позволяло, например, совершенно прозрачным образом обрабатывать ошибки отсутствия страницы виртуальной памяти в режиме ядра (Windows NT позволяла деражать часть кода и данных режима ядра в виртуальной, выгружаемой на диск, памяти, и в те времена жуткого дефицита памяти, когда она появилась, это было для нее существенным плюсом).
Работало это примерно так. При обращении к отсутствующей в RAM странице виртуальной памяти аппаратура генерировала прерывание, которое обработчик этого прерывания преобразовывал в исключение. Обработчик исключения отсутствия страницы находившийся где-то далеко вверху стека вызовов, проверял, что ядро в момент прерывания находилось в режиме, позволяющем запустить операцию ввода вывода и подождать её завершения (IRQL<2), запускал операцию чтения из страничного файла и ждал завершения операции. После успешного завершения чтения обработчик выходил из ожидания и возвращал это самое значение EXCEPTION_CONTINUE_EXECUTION — после чего прерванный поток выполнения мог выполняться дальше, как будто ничего не произошло.
В Visual C/С++ SEH была реализована через специфичное для платформы расширение языка (__try… __except) — которое было, естественно, никуда не переносимо и, к тому же, конфликтовало с механизмом обработки исключений языка C++ (впрочем, это — особенность реализации: в Delphi — не конфликтовало, т.к. тамошний механизм исключений в языке был построен как раз на SEH).
Потому, по-видимому, SEH осталась специфичной чертой Windows, к тому же — не часто используемой.
Так что это хорошо, что старая идея обретает новую жизнь на уровне широко распространенного языка, пусть и под новым именем. Но, естественно, новая жизнь — это не просто повторение старого: доработка неизбежно потребуется. Например, как в статье написано, для совмещения концепции возобновления выполнения после исключения с современной моделью асинхронной обработки.
Интересно, как именно мерялись вот эти технические характеристики в спецификации:
Произвольное чтение/запись 4K QD16 WCD (количество операций ввода-вывода в секунду): 170 IOPS / 440 IOPS
Средняя задержка: 4,16 мс
Вопрос такой, потому как для семитысячника (7200 об/мин) они ни в какие ворота не лезут. Вот в тесте, результаты которого приведены в тексте статьи, характеристики получились вполне адекватные тому, что обычно предполагается для семитысячников: для произвольного доступа с блоком по размеру сектора (4КБ, как я понимаю) получилось 74 IOPS и ~13ms для времени доступа.
Поэтому хотелось бы узнать методику, по которой получены цифры из спецификации, чтобы понимать, что именно я не понимаю.
Странно мне это. Я Немцова, Адамова и т.п. читал в свое время (вторая половина 70-х) в обычной городской библиотеке (хотя и не новой, в неё ещё мой отец ходил). Правда — исключительно в читальном зале: на дом такие книжки повышенного спроса — не только 50-х, но и современные на тот момент детективы и фантастика — не выдавались, чисто чтобы им ноги не приделали.
А 3-томник Казанцева, купленый каким-то образом родителями в те же 70-е, у меня до сих пор в шкафу валяется.
Прежде всего, в ней не отражена недостаточная надежность социологических данных, на которых основаны её выводы. В частности, исследование Deloitte, на отчет по которому ссылаются в статье как на источник данных о сравнительной популярности и уровне доверия для Интернета и других СМИ, проводилось путем опроса в Интернете(sic!), о чем Deloitte честно пишет — — и не забывает сделать оговорку о том, что это ведет к неточности результатов: Более того в отчете, к сожалению, не указан способ привлечения пользователей Интернета к опросу. А это, на мой взгляд, существенно, т.к. при пассивном привлечении путем размещения на каких-либо ресурсах (т.е. в нем участвовали те, кто его смогли увидеть, а не те, кого заранее выбрали организаторы опроса) активные пользователи Интернета имеют больший шанс поучаствовать в опросе, чем те, кто пользуется Интернетом от случая к случаю — что ещё больше смещает выборку и делает результат ещё менее надежным. Но, к сожалению, автор статьи не сделал оговорку о том, что что результаты Deloitte могут иметь систематическую ошибку, приводящую к завышению важности Интернета как медиаканала.
Далее, вывод из исследования Deloitte о том, что приводится, к сожалению, по отношению ко всему Интернету чохом, без указания на то, что такой уровень доверия имеет лишь категория «Интернет (новостные, аналитические, официальные сайты)». Но — отнюдь не категория «Интернет (социальные сети и блоги)», уровень доверия для которой (13%) меньше, чем для телвидения (28%) и, хотя и повысился по сравнению с прошлым годом, всё ещё находится ниже достигнутого в 2015 году уровня (15%). А поскольку в статье далее подробно обсуждаются только социальные сети и блоги, но не новостные и официальные сайты, то в результате прочтения статьи может возникнуть ложное впечатление, что блоги/социальные сети пользуются большим доверием, чем телевидение. К сожалению, автор статьи ничего не сделал, чтобы не допустить этого, ложного, впечатления у читателей.
Указанные недостатки, на мой взгляд, существенно снижают ценность статьи как источника информации для читателей, не имеющих возможности или желания подробно анализировать источники, использованные в статье.
Что касается вашего возражения, то оно возражением по сути не является. Всё правильно: на рынок выходят покупатели и продавцы не только со своими продуктами и спросом на них, но и со своими причудами. А уж механизм конкуренции оценивает, насколько эти причуды полезны для общества. И результаты оценки могут быть весьма неожиданными — например, появляется рынок «крафтовых» продуктов. Или — Hi End аудиотехники с его «теплым ламповым звуком».
Сказать заранее, что именно решит рынок, трудно, а ошибиться — легко. Поэтому вы имеете полное право выбирать, как именно делать свою работу — до тех пор, пока условия на рынке это вам позволяют. Но если не позволяют, то единственный полезный подход — не ныть, а смириться и зарабатывать деньги.
PS То, что программисты могут сейчас выбирать, на кого работать — это верно. Но не факт, что это будет верно в будущем — потому что, например, это было совсем неверно лет 25 назад на территории СНГ.
Ибо в Interbase в некие древние времена (ещё когда Delphi было модным средством разработки приложений) мне как-то пришлось воспользоваться gfix на боевой БД — и это было сильно проще, чем описанные в статье мучения.
Ну, не скажите: тут недавно как раз всплыла ссылка на типовой креатив интеллигента советского разлива с Прекрасного.it на тему «я — элита, а вокруг меня — быдло», причем — в контексте того, что автору комментария она глаза на мир открыла.
То есть, его почему-то не устраивает простой подход, что деньги он получает, продавая свой труд на рынке рабочей силы покупателям, они же — предприниматели. Что он на работе не самовыражается, не творит шедевры, а является винтиком в народнохозяйственном (он же — экономический) механизме. И польза его деятельности для народного хозяйства (то есть, для остальных людей) измеряется исключительно получаемой зарплатой. Потому что именно так работает рыночный механизм регулирования экономики — наилучший из доступных человечеству механизмов, заменить который на что-то, более эстетическое и рационально устроенное и, при этом, не менее эффективное, пока что не получается.
Впрочем, поскольку мы живем в свободном обществе, никто не мешает автору того поста, как и другим желающим странного, заниматься художественным программированием за свой счет. Более того, если эта деятельность вдруг окажется достаточно нужной для общества, то и материальное вознаграждение за неё не заставит себя ждать.
Как-то так.
А частью программы (реализацией этого общего принципа), причем, в данном случае — коренной, составляющей основную её логику, являются struct reactor и работающие с ними функции в программе автора.
В более сложных программах разные её части могут реализовывать разные общие принципы. Например, в одной и той же программе для современных (в смысле не 3.x) версий Windows может быть, например, как графическая часть на основе событийно-ориентированного программирования, так и логика обработки подключений клиентов по сети с использованием Winsock, использующая другую парадигму. Например — выделенные потоки для каждого клиента, такие программы можно легко и просто клепать в Delphi: там графические и сетевые компоненты для накидывания на форму берутся из одной кучи.
Тут есть ещё одна проблема (или другая сторона той же проблемы): число потоков для такой архитектуры подобрать трудно. Если потоков будет слишком мало, то пул часто будет истощаться из-за того, что они ожидают завершения блокирующих операций ввода/вывода. Если много, то избыточное число активных потоков приведет к потерям на частое переключение между ними.
Для эффективной реализации парадигмы пула потоков нужен механизм в ОС, который, даже при наличии задач в очереди обработки, реализует запуск на обработку только ограниченного (например, равного числу ядер в системе) числа активных потоков, меньшего полного числа потоков в пуле. Такой механизм должен отслеживать число активных (не заблокированных на вводе/выводе) потоков, и если их становится мало, запукать обработку в дополнительных потоках из пула. При наличии такого механизма истощение пула потоков становится менее вероятным, при том что потери на конкуренцию между активными потоками остаются на приемлемом уровне, т.к. число активных потоков привышает желательное только на короткое время.
В Windows такой механизм — IO сompletion port — есть уже довольно давно. Но вот в часто используемом для создания веб-серверов Linux с таким механизмом, насколько мне известно(если я ошибаюсь — просьба поправить), есть (или были до недавнего времени) проблемы, а потому подход с пулом потоков в Linux работает (или работал) сильно хуже событийно-ориентированного неблокирующего подхода (как в этой статье).
PS А ещё меня в очередной раз умилил пример «проектирования на основе паттернов» (наиболее заметной частью которого IMHO является назначение красивых имен давно известным приемам программирования) из названия статьи: в данном случае красивым словом Реактор(Reactor) названо давно и хорошо известное (в частности, GUI Windows реализован именно в этой парадигме) событийно-ориентированное программирование. С одной стороны, конечно, не могу отрицать полезность паттернов — красивые имена повзоляют легче запоминать приемы (действительно полезные), но вот с другой стороны не умеющему «в паттерны» трудно сразу понять, что речь на самом деле идет о чем-то хорошо ему знакомом.
«Некоторая виртуализация» заключалась в том, что эти копии DOS могли работать независимо дург от друга и параллельно, в режиме вытесняющей многозадачности. А то, что они использовали один и тот же код ядра, то это и в других гипервизорах встречалось: например, в VM/SP, где все VM с одной и той же хранимой системой (например, CMS) использовали один и тот же код ядра.
Да, тут требуется уточнение: речь была конкретно о версии Desqview 386 (с которой я некогда реально работал).
В курсе: как вы заметили, я отнюдь не утверждал, что Quaterdeck научилась это делать первая.
Факт состоит в том, что Desqview (равно как и Win3.x Extended mode) выполнял фукцию управляющего ПО, работавшего на уровне ниже ОС (DOS в конкретном случае), с более высокими привилегиями, и определявшего, что именно из аппаратуры и прерываний доступно вышележащей ОС — что обычно как раз и называется в наше время словом «гипервизор» (да, раньше такого слова не было, в VM/SP, к примеру, этот компонент именовался незатейливо: Control Program).
Windows 95 от Windows 3.x Extended Mode в этом плане архитектурно отличалась мало: и WIN386.EXE из Win3.x, и VMM32.VXD выполняли примерно одни и те же функции компонента Virtual Machine Manager: управление вытесняющей многозадачностью для VM (выполняющих DOS и системной, выпоняющей Windows), обработку прерываний, управление памятью… Подробности (которые сейчас представляют, разве что чисто исторический интерес) можно прочесть, например, в старой книге Шульмана «Неофициальная Windows 95». Ну, а режим совместимости — он был поблажкой именно ради совместимости с TSR(резидентными программами для DOS), работающим с обращениями к файловой системе и диску (которые были как полезные, ради которых эта проверка делалалсь, так и наоборот — то есть вирусы). А так, в принципе, Windows могла его и не включать, и работать с файловой системой, не используя код DOS (и Win 3.11 тоже могла, называлось это 32BFA, VxD под это в ней был, только им часто не пользовались, потому как в нем как раз упомянутого режима совместимости не было)
Компания называлась Quarterdeck (полностью — Quarterdeck Office Systems), выпущенный ей продукт для виртуализации DOS (в котором можно было запускать несколько DOS VM в режиме виртуализации реального режима — V86) — DESQView.
Спецификация EMS к виртуальнм машинам прямого отношения не имела: она описывала, как можно отображать в доступное адресное пространство объем памяти, больший, чем пресловутые 640К(в реальности — 1М, т.к. оставшиеся 384К были зарезервированы под адресное пространство для ПЗУ и памяти, используемой переферийными устройствами) — через специально отводимое перемещаемое по этой большей памяти «окно». Такие решения по расширеню адресуемой памяти в истории развития вычислительной техники возникали неоднократно (кто был первый — даже не знаю). К примеру, когда развитие ОС для x86 уперлось в ограничение 32бит адреса, то в Windows Server появилось аналогичная по своей сути спецификация доступа к памяти свыше 4ГБ — AWS.
В случае EMS изначально предполагалось, что управление отображением будет реализовано специальной аппаратурой (размещенной вместе с дополнительной памятью на плате расширения или выполненной внутри чипсета). Однако уже упомянутая Quaterdeck научилась использовать вместо этой аппаратуры появившийся в 80386 режим виртуализации V86. Для этого она выпустила драйвер QEMM-386. Который тоже отчасти был чем-то вроде «одноместного гипервизора»: DOS после инициализации этого драйвера работала не в реальном, а в V86 режиме процессора, но — с прямым отображением почти всей памяти (виртуальные адреса были равны реальным) — кроме области окна, в которую этот драйвер отображал в соотвествии со спецификацией EMS имеющуюся в системе оперативную память, находящуюся над границей 640К.
PS А ещё, кстати, гипервизором для DOS была и Windows(в расширенном режиме) — в ней DOS-окна запускались как раз в режиме V86.
Я правильно понял по этим фразам, что вы рассматриваете Domain Driven Design не как средство решения конкретных проблем бизнеса, способное повысить его эффективность, а как средство защиты программистами, его освоившими, своих привилегий (в виде высокой зарплаты и т.п.)?
Если я понял неправильно, то поясните, пожалуйста, что вы на самом деле имели в виду.
Хотите примеров — их есть у меня.
Для многих наших современников словосочетание «Фома неверующий», так же, как и 100 лет назад вызывает в памяти совершенно конкретную фигуру — апостола Фому. Но вот для совеских детей это было совсем не так: у них это словосочетание ассоциировалось совсем с другой историей: «В одном переулке стояли дома/В одном из домов жил упрямый Фома» — было такое, весьма забавное и весьма поучительное стихотворение одного из советских поэтов. То есть, у советской пропаганды более ранних времен вполне получалось заставить забыть имя библейского персонажа. Библейского! Из глубины веков!
А тут — имен каких-то диссидентов, которых почти никто в СССР и не знал, испугались. И ведь при правильном подходе, никто бы и не узнал (почти, в пределах статистической погрешности, которую органы могут и подчистить, если что), что это — не имена вымышленных героев из фантастики, а неких реальных людей.
Деградация — налицо.
Вообще-то, RDP там есть и был изначально. Другое дело, что после активации RDP нужно было обязательно перезагружать сервер.
В частности это касается и идеи возобновления выполнения выполнения как способа обработки исключений.
Первая известная мне реализация появилась в продукте, с которым почти все наверняка сталкивались — в API ядра Windows NT (которая является предшественником всех современных версий Windows) и основанном на нем API Win32. Называется она Structured Exception Handling (SEH), существует с самой первой версии WinNT и широко используется самим ядром. В целом SEH аналогична по функциональности другим системам обработки исключений, но ней есть дополнительный вариант — продолжить выполнение кода после его прерывания: для этого обработчик исключения должен вернуть значение EXCEPTION_CONTINUE_EXECUTION.
Это позволяло, например, совершенно прозрачным образом обрабатывать ошибки отсутствия страницы виртуальной памяти в режиме ядра (Windows NT позволяла деражать часть кода и данных режима ядра в виртуальной, выгружаемой на диск, памяти, и в те времена жуткого дефицита памяти, когда она появилась, это было для нее существенным плюсом).
Работало это примерно так. При обращении к отсутствующей в RAM странице виртуальной памяти аппаратура генерировала прерывание, которое обработчик этого прерывания преобразовывал в исключение. Обработчик исключения отсутствия страницы находившийся где-то далеко вверху стека вызовов, проверял, что ядро в момент прерывания находилось в режиме, позволяющем запустить операцию ввода вывода и подождать её завершения (IRQL<2), запускал операцию чтения из страничного файла и ждал завершения операции. После успешного завершения чтения обработчик выходил из ожидания и возвращал это самое значение EXCEPTION_CONTINUE_EXECUTION — после чего прерванный поток выполнения мог выполняться дальше, как будто ничего не произошло.
В Visual C/С++ SEH была реализована через специфичное для платформы расширение языка (__try… __except) — которое было, естественно, никуда не переносимо и, к тому же, конфликтовало с механизмом обработки исключений языка C++ (впрочем, это — особенность реализации: в Delphi — не конфликтовало, т.к. тамошний механизм исключений в языке был построен как раз на SEH).
Потому, по-видимому, SEH осталась специфичной чертой Windows, к тому же — не часто используемой.
Так что это хорошо, что старая идея обретает новую жизнь на уровне широко распространенного языка, пусть и под новым именем. Но, естественно, новая жизнь — это не просто повторение старого: доработка неизбежно потребуется. Например, как в статье написано, для совмещения концепции возобновления выполнения после исключения с современной моделью асинхронной обработки.
Вопрос такой, потому как для семитысячника (7200 об/мин) они ни в какие ворота не лезут. Вот в тесте, результаты которого приведены в тексте статьи, характеристики получились вполне адекватные тому, что обычно предполагается для семитысячников: для произвольного доступа с блоком по размеру сектора (4КБ, как я понимаю) получилось 74 IOPS и ~13ms для времени доступа.
Поэтому хотелось бы узнать методику, по которой получены цифры из спецификации, чтобы понимать, что именно я не понимаю.