OSDev

У меня никогда не было проблем с API других систем, где создание нового процесса делается более человеческим образом.



Неправда Ваша. В RSX-11 потоков не было, только задачи; в OS/360 потоки были не обязательны для младших вариантов системы -- однако и там, и там ввод-вывод был асинхронным.

Не соглашусь. Вы, конечно, имеете полное право утверждать, что на Си писать всегда лучше, чем на ассемблере, а я вот утверждаю: нет, часто не лучше, а хуже. Надёжность кода на Си будет крайне низка, читабельность -- очень посредственная, и практически все преимущества над асмом сводятся в скорости набора исходников. Лично меня такое положение не устраивает, поэтому я Си не использую и использовать не буду, и если у меня стоит выбор -- Си или ассемблер -- я пишу на ассемблере. (Правда, мне не приходится создавать программы для работы с СУБД и т.п. "высокоуровнево-прикладной" код, так что говорю только о системном).



По-настоящему хороший код на Си написать вообще близко к невозможному, и для этого надо отказываться от многих специфических особенностей языка. В частности, категорически нельзя использовать операцию ?, кодируя явным образом if-else (ну или разбивать ? на несколько строк, где чётко видно, где какая часть). Ни в коем случае нельзя использовать for для чего-либо, кроме традиционного цикла с заранее известным числом элементов, полностью аналогичного паскалевскому for'у, ну и так далее. Любое отклонение от подобных правил убивает читабельность программы, поскольку приходится каждый раз расшифровывать, что же на самом деле стоит за той или иной конструкцией. В результате приходим к "паскалевскому" стилю программирования, но без паскалевского контроля типов и других вещей, направленных на повышение надёжности.



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



Извините, полный бред. "Многа-многа букаф" в Аде как раз резко повышают читабельность по сравнению с Си, где что ни строка -- то набор специальных символов, через который ещё продраться надо, чтобы понять смысл этой "шифрограммы". Даже несчастный if или for невозможно записать как минимум без скобок. А многие ещё и пробелы не ставят, и попробуй сходу увидеть, что там -- вызов функции или условный оператор... Операторы с ? вообще абсолютно нечитаемые, поскольку и условное выражение, и оба вычисляемых по условию сливаются в одну сплошную кашу...

А begin-end'ы бесконечные -- это характерная черта только и исключительно Паскаля, а не прочих языков, к нему восходящих. В той же Аде эта парочка используется только для начала и конца кода подпрограммы (процедуры или функции), а также в случае, если внутри специально производится группировка операторов в блок (оператор declare-begin-end). Во всяких там условных операторах и прочих циклах никаких begin'ов нет. И это не говоря о том, что сам по себе begin-end читабельней, чем выполняющие совершенно ту же функцию в Си { }, особенно при слабом зрении -- хотя б потому, что { } очень легко спутать с [ ] или ( ), если не приглядываешься или шрифт не на весь монитор.

Я предлагаю всё же на "ты" перейти . ОК?


Я ж говорю, по категоричности здесь мало кто сравнится с тобой . Ну да ты сам всё провоцировал-провоцировал своей Адой. Я своё мнение на тему "Ada vs C" высказал, а биться головой об стенку не буду.


Ну да, я всегда говорил, что программист должен обладать хорошим зрением. А то перепутаешь "." и "," и Voyager мимо цели пролетит .

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Из плюсов кодирования на Си замечу один - наличие хорошего компилятора для него: тот, который в MSVS. Если чуток пошаманить в настройках, то код очень хороший делает. К сожалению, не натыкался на компиляторы подобного качества для других языков. Дизассемблировал код, который мне делал GCC со всеми видами оптимизации - несколько хуже. Думаю (но не могу однозначно утверждать), все его переделки для других языков еще хуже, т.к. их почти никто не использует и поэтому им мало уделяют внимания. Творения Borland (и их производные) для компиляции паскаля... гхм... не блистают чудесами оптимизации. Хотя мне из ЯВУ ближе паскаль (аду не пробовал).

Привычка свыше нам дана, как казал поэт. Чтоб писать на "ты" мне надо думать, а это было бы ошибкой, как сказал другой классик (В переводе на русский: мне форма обращения безразлична, пока всё в рамках внешних приличий, но сам я обычно пишу на автопилоте, откуда и Вы).



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

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

Ну а Си/Си++ ругаю как самые распространённые языки, тем более позиционируемые как предназначенные для околосистемного быдлокодинга Вряд ли Жаба или Си-шарп много лучше в плане синтаксиса, чем Си, от синтаксиса которого они происходят (хотя быть хуже по надёжности, пожалуй, невозможно), но их же для системного программирования, вообще говоря, не используют, поэтому на них и не набрасываюсь -- да и работать на них не приходилось, в отличие от Си/Си++ (которые до сих пор вспоминаю с содроганием).



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

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



Для АРМа код от ГЦЦ очень плох, да и для ИА-32, мягко говоря, качеством не блещет. Одинаковый по смыслу код на Аде и на чистом Си в ГЦЦ порождает одинаковый ассемблерный код, поскольку оптимизатор и кодогенератор у них общий, различаются только фронт-энды. Вот если писать с использованием ООП, то, надо полагать, разница будет между кодом для Ады и для Си++: идеология там всё ж несколько отличается. Но это не проверял.

API как выглядел у этого концептуально?

Концептуально неблокирующий ввод-вывод выглядит так (псевдокод):



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

При асинхронном выводе без потоков, мы после записи, должны все равно как-то убедиться, что наш блок данных ушел...
Типа:



Если не ждать пока все записалось, это конечно асинхронный вывод и он вполне себе реализован в UNIX-ах. Это называется запись в файл без ожидания. Обычно включается выключается опциями операционной системы.

Вобщем насчет асинхронного ввода-вывода без потоков интересно. Как это выглядит синтаксически? Чем это отличается от обычного кэширования файла. Т.е. запись прошла в кэш и система вернула управление прикладному коду.

Под Windows приходилось пользоваться асинхронным API. От неблокирующего это концептуально отличалось только тем, что вместо того, чтобы сначала запросить у системы разрешение на запись. Нужно было сначала производить запись до тех пор пока система не вернет, код ошибки, что буфер заполнен. После этого уже можно было заказывать WaitFor...Object() на соответствующем handler-е.

Принципиально есть лишь два вызова API -- запустить ввод-вывод и ожидать наступления события, причём второй не всегда обязателен. Технически вызовов могло быть и несколько (например, в RSX-11 вообще весь ввод-вывод осуществлялся вызовами QIO$ и QIOW$, причём второй был предназначен для упрощения организации синхронного ввода-вывода: по сути, он представлял собой обычный асинхронный QIO$, сразу за которым следовал перевод задачи в ожидание до завершения операции ввода-вывода; в OS/360 были отдельные основные вызовы READ и WRITE плюс ещё всякие управляющие, которые я уж и не помню за давностью лет), но суть от этого не меняется.

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

2. Занимаешься дальше своими делами (например, перерабатываешь данные, поступившие от уже завершившихся операций ввода-вывода).

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

В общем, для тех случаев, когда асинхронный ввод-вывод не нужен, для программиста нет никаких дополнительных сложностей: он работает с синхронным, даже, возможно, не подозревая, что реально он остаётся асинхронным, а синхронизация достигается немедленным переводом задачи (потока) в ожидание до завершения ввода-вывода. Зато, когда нужен асинхронный, подменить его чем-то другим весьма сложно, и без всяких дополнительных плясок не обойдёшься. Например, в Вашем примере надо предварительно опрашивать состояние, анализировать его и т.п. -- а нафиг это нужно, если, например, у меня задача-архиватор, которая использует асинхронный ввод-вывод только для того, чтобы упаковывать уже считанные в один буфер данные в то время, как продолжается ввод следующей порции во второй буфер, а уже упакованное содержимое третьего записывается в выходной файл?

Кстати говоря, к кэшам асинхронный ввод-вывод никакого отношения не имеет. Система может иметь кэш, а может и не иметь (и реально обычно не имела в те годы: не те объёмы памяти были, чтобы хранить в ОЗУ что-либо, кроме разве что оглавления текущих используемых каталогов). Кроме того, часто операция выполнялась прямо в памяти задачи без лишних пересылок в промежуточные системные буферы.

Не надо своё личное негативное отношение к языку возводить до вселенского уровня. Это, как минимум, неправильно.


Вот никак не могу назвать себя быдлокодером, хотя с некоторых пор стараюсь писать только на С++. И точно также не могу назвать быдлокодингом десятки замечательных проектов, написанных на С/С++.


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

Что касется этой холиварной темы, я в последний раз выскажу своё мнение, резюмируя его, и, надеюсь, это поможет понять (я не призываю принять) любовь массы людей именно к этой идеологии.
Назовём их двумя подходами: текстовый и символьный. Ада, Паскаль, Модула - типичные текстовые языки. С/С++, С#, Java - типичные символьные. Я полагаю (и есть основания считать, что это действительно так), что образ мышления людей отличается. По крайней мере, в среде математиков преобладают два разных подхода - вербальный и графический. Так вот, одни люди проще понимают мысль выраженную в словесной формуле, другие - в картинке (диаграмме, схеме...). Это именно разница в мышлении и нельзя сказать, что одни хуже, другие лучше. Я - классический случай графического мышления. Если я смотрю на блок кода, окружённый симметричными символами, то смысл написанного мне графически сразу очевиден, то есть мне не нужно читать, что там написано. Если же я читаю текстовое описание, принятое в текстовых языках, то вынужден делать двойную работу по переводу в образное представление. Я начал своё образование и работу с Паскаля, поэтому импринтинг здесь ни при чём. Это именно разница в мышлении, а никоим образом не "вселенское зло".

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Спасибо.



Сallback иными словами. В контексте какого-то ядерного треда. В UNIX есть похожая штука. Называется сигналы. Очень неудобная. В контексте callback-а ничего серьезного делать нельзя. Только разве что переменную какую-нибудь выставить. Плюс сигналы прерывают другие операции ввода-вывода. Что приводит к лишней логике в прикладном коде.


Поступившие данные вообще не вопрос. К асинхронности отношения не имеют. Предварительная проверка как раз и говорит о том, что есть данные на обработку. Если это ввод. И что есть достаточно места в выходном буфере для вывода данных. Если это вывод. Т.е. данные поступают с точки зрения прикладной программы асинхронно.



Если ожидаешь события. То как бы это то же самое, что и неблокируемый вариант. Только там ждешь когда можно записать. А тут ждешь, когда уже записалось. Чтобы опять же можно было снова записать.

Про обработчик события - это уже повторение пункта первого.



Согласен асинхронно - красиво. Но по большому счёту, выигрыш реально возникнет лишь в случае, если вводом-выводом непосредственно из памяти программы занимается не CPU, а отдельный контроллер. Иначе это лишь синтаксический sugar. А внутри, все равно цикл обработки прерываний. Т.е. событий ввода вывода. Идеология for(;;) { select(); ... } близка к идеологии обработки событий.