Исправление DRVTiny, (текущая версия) :
Немного офтопик, но есть у меня вопрос по IO-асинхронщине, который я пока не видел, чтобы кто-то задавал хотя по мне он прямо на поверхности лежит: а ничего, что данные, запрошенные у того или иного устройства, будут считаны приложением далеко не сразу, а тогда, когда дойдёт очередь до соотв. обработчика? Ну т.е., положим, в не вполне корректно написанном приложении один поток/обработчик взял данные с диска и начал этак неспеша их перемалывать, а тем временем где-то уже давным давно пришли данные от сетевого устройства, но обработать их некому... Не приводит ли это к тому, что на задержки самих IO-устройств как-то неожиданно накладываются задержки, связанные с выстраиванием в цепочку async-обработчиков? И если раньше мы видели в общем-то реальную IO-задержку, то сейчас это может быть запросто вообще всё, что угодно...
Я понимаю, что и в случае параллельной обработки тоже данные читаются тоже в порядке приоритета, но там хотя бы сама ОС передаёт процессу управление тогда, когда его можно разблокировать по вводу-выводу - и это в рамках вытесняющей многозадачности (ОС никого не ждёт, просто переключает при следующем «тике» прерывания таймера).
А вот тормозящий всех IO-поток в рамках конкурентной модели - никто не «пнёт»....
Исправление DRVTiny, :
Немного офтопик, но есть у меня вопрос по IO-асинхронщине, который я пока не видел, чтобы кто-то задавал хотя по мне он прямо на поверхности лежит: а ничего, что данные, запрошенные у того или иного устройства, будут считаны приложением далеко не сразу, а тогда, когда дойдёт очередь до соотв. обработчика? Ну т.е., положим, в не вполне корректно написанном приложении один поток/обработчик взял данные с диска и начал этак неспеша их перемалывать, а тем временем где-то уже давным давно пришли данные от сетевого устройства, но обработать их некому... Не приводит ли это к тому, что на задержки самих IO-устройств как-то неожиданно накладываются задержки, связанные с выстраиванием в цепочку async-обработчиков? И если раньше мы видели в общем-то реальную IO-задержку, то сейчас это может быть запросто вообще всё, что угодно...
Я понимаю, что и в случае параллельной обработки тоже данные читаются тоже в порядке приоритета, но там хотя бы сама ОС передаёт процессу управление тогда, когда его можно разблокировать по вводу-выводу - и это в рамках вытесняющей многозадачности (ОС никого не ждёт, просто переключает при следующем «тике» прерывания таймера).
А вот заснувший IO-поток в рамках конкурентной модели - никто не разбудит....
Исходная версия DRVTiny, :
Немного офтопик, но есть у меня вопрос по IO-асинхронщине, который я пока не видел, чтобы кто-то задавал хотя по мне он прямо на поверхности лежит: а ничего, что данные, запрошенные у того или иного устройства, будут считаны приложением далеко не сразу, а тогда, когда дойдёт очередь до соотв. обработчика? Ну т.е., положим, в не вполне корректно написанном приложении один поток/обработчик взял данные с диска и начал этак неспеша их перемалывать, а тем временем где-то уже давным давно пришли данные от сетевого устройства, но обработать их некому... Не приводит ли это к тому, что на задержки самих IO-устройств как-то неожиданно накладываются задержки, связанные с выстраиванием в цепочку async-обработчиков? И если раньше мы видели в общем-то реальную IO-задержку, то сейчас это может быть запросто вообще всё, что угодно...