achesnokov писал(а):
Сallback иными словами. В контексте какого-то ядерного треда. В UNIX есть похожая штука. Называется сигналы. Очень неудобная. В контексте callback-а ничего серьезного делать нельзя. Только разве что переменную какую-нибудь выставить. Плюс сигналы прерывают другие операции ввода-вывода. Что приводит к лишней логике в прикладном коде.
Да, нечто вроде этого. Однако подобный механизм (в RSX-11 называется асинхронными системными прерываниями -- AST; в OS/360 -- подпрограммами выхода) в хорошо известных мне системах не запрещает абсолютно ничего, и, в частности, не прерывает другие операции ввода-вывода: всё как работало, так и будет работать. На этих механизмах в означенных системах много что построено; например, взаимодействие с пользователем.
Цитата:
Поступившие данные вообще не вопрос. К асинхронности отношения не имеют. Предварительная проверка как раз и говорит о том, что есть данные на обработку. Если это ввод. И что есть достаточно места в выходном буфере для вывода данных. Если это вывод. Т.е. данные поступают с точки зрения прикладной программы асинхронно.
Возможно, мы друг друга не до конца понимаем. Ведь я говорю о работе, не связанной с текущей операцией ввода-вывода: задача что-то своё делает и одновременно с этим идёт ввод-вывод, т.е. достигается совмещение ввода-вывода и обработки, а значит, исключаются ненужные простои.
Цитата:
Если ожидаешь события. То как бы это то же самое, что и неблокируемый вариант. Только там ждешь когда можно записать. А тут ждешь, когда уже записалось. Чтобы опять же можно было снова записать.
Ага, но тут ждёшь только тогда, когда это реально нужно, т.е. когда нет никакой работы, которую можно было бы сделать. Причём это ожидание эффективнее: если "там" надо регулярно опрашивать устройство, чтобы узнать, можно ли писать дальше, тот тут ждёшь завершения операции, для чего опрос не нужен: просто говоришь системе, что ждёшь, и она останавливает поток до выполнения условия ожидания (ну или до наступления таймаута, ежели таковой задан).
Цитата:
Согласен асинхронно - красиво. Но по большому счёту, выигрыш реально возникнет лишь в случае, если вводом-выводом непосредственно из памяти программы занимается не CPU, а отдельный контроллер. Иначе это лишь синтаксический sugar. А внутри, все равно цикл обработки прерываний. Т.е. событий ввода вывода. Идеология for(;;) { select(); ... } близка к идеологии обработки событий.
Ага, но дело-то в том, что в PDP-11 все быстрые устройства (диски и ленты) имели возможность прямого доступа к памяти и только так и работали; программная пересылка применялась лишь с медленными устройствами (терминалами, принтерами и т.п.). Ну а в мэйнфреймах ввод-вывод вообще всегда выполняется средствами так называемых каналов ввода-вывода -- по сути, узкоспециализированных процессоров, которые работают параллельно с основным, обращаются к нужным областям памяти и т.д. Основной процессор, запуская ввод-вывод, указывает каналу адрес устройства и адрес начала канальной программы -- и всё, дальше всё сделает канал, дёрнув ЦП, когда операция будет завершена. Соответственно, асинхронный ввод-вывод там очень эффективен. На ПК меня дико бесило отсутствие нормального прямого доступа к памяти: контроллер 8237 -- это жуткое ублюдство. Вот PCI-устройства уже могут выполнять его в стиле PDP-11, но они появились далеко не сразу.