Проклятая тема

[metaclass]

Как известно, в программировании есть несколько проклятых тем. Т.е. задач, которые сами по себе просты, но их общего (повторно-используемого, кросс-платформенного, не заставляющего глаза течь кровью) решения не бывает и приходится каждый раз мутить какие-то велосипеды.
Одна из таких тем: прерывание длительных и блокирующих операций. Смежная - показ прогресса для таких операций. Вот, например, в контексте скалы: http://ru-scala.livejournal.com/36634.html
Почему эта тема проклята?
Во-первых, прерывание означает либо два потока, либо callback изнутри операции, вызывающий проверку наличия ввода от пользователя (Application.DoEvents/Application.ProcessMessages). Средний разработчик от многопоточности и callback бежит как от огня.
Во-вторых, i/o операции изначально сами по себе блокирующие. Всякие там чтения из сокетов, файлов(на сгнившей файловой системе примонтированной с выключенного сервера), rs232-портов с забытыми таймаутами и прочего зла. Реализация асинхронного i/o - жесточайшее уныние, что с overlapped, что с completion ports, что с select и прочими epoll.
В уютной сишечьке или недалеко от них ушедших C++ и Delphi - это по крайней мере, помещается в мозг, в дотнетах же, жабах, рантаймах хаскеля и прочих порождениях геенны огненной - либо авторы рантайма озаботились прерыванием операций, либо изобретение велосипеда вырождается в чад угара и лавирования между GC и разными уровнями представления данных.
Во-третьих, "у меня на столе все работает". Когда сервера не выключаются, сеть работает, диски без бэдов и железо отвечает вовремя - операции отрабатывают быстро, или можно их выполнять мелкими блоками и проверять какие-нибудь флаги отмены.

В-четверых, часто эти операции завернуты в десятки слоев чужих библиотек, например, "выполнение запроса к БД и выборка неизвестного количества миллионов записей, потому что база не знает сколько записей подпадает под условие". Если повезет - метод "прервать и свалится с исключением в потоке выполнения запроса" будет в API и даже после его применения внутренние структуры данных не превратятся в кашу. Если нет - то только убивать себя о стену.

Comments

[http://users.livejournal.com/_slw/]

в rt-11 прерывание операций было сделанно и работало зашибись.
как и асинхронный ввод-вывод, кстати.

[antontsau.livejournal.com]

ну и кстати нет. У каждого уважающего себя драйвера была критическая часть, которую даже прервать было нельзя. Соответственно если оно косело в этом месте (одно слово считалось, а на втором железо обвисло), а афтырь случился мудак и не предусмотрел, то валилось все вообще. Хотя и редко, там ничего сложного в такие критические части писать было не принято.

[http://users.livejournal.com/_slw/]

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

[antontsau.livejournal.com]

ну не совсем уж косело, но скажем обещало дать байт, а не отдавало, и крутился драйвер в каком-то тупом цикле ждал какой-нибудь бит готовности. А вструмлять массу проверок, таймаутов и прочего в критическую чаксть драйвера тоже считалось зело нехорошо. По уму конечно надо было все такое тут же выносить в некритическую чать... но тогда могло и не успеть, если этот байт слишком быстро лез. Чего-то вспоминается, что такая проблема была при напейсании драйвера винта для двк3-4, там контроллер был шибко умный и быстрый, но шибко глюкавый, и постоянно завешивался.

[http://users.livejournal.com/_slw/]

что значит обещало и не отдавало?
обещало -- это обычно 000200 в CSR. как после этого можно не отдать что-то в дата?
более того, хорошим тоном не в цикле крутиться, а 000100 в CSR поставить и отдаться до прерывания.

а контроллер винта по DMA работать должен.
как и дисковода (если он не MX, разумеется. но MX жить не должен).
он, собственно и работал, кажется, потому как загрузка из пульта с него была возможна без написания программ, просто программированием регистров.

[antontsau.livejournal.com]

обещало - это прерывание дернуло, а бит не выставило. Что делать? Втупую вернуться, валиться с ошибкой, попробовать еще разок, крутиться ждать? Зависит от афтыря.

Ну, да, говорю же, все в некритическую часть. Но если оно может появиться через (условно) секунду, а может и через 100 мксек уже протухнуть (придет следующий), то механизм с прерываниями может и не успеть, особенно если еще кто-нибудь в такую же критическую часть уедет и не вернется. Пока это какой-нибудь tty на 9600 - да плевать, успеет сто раз. А если тот же тты но на 115200?

Не помню уже в чем там была проблема, но как-то не получалось. Контроллер не тот что от СМ, а тот что от ДВК, он там вуууууумный был как вутка.

[http://users.livejournal.com/_slw/]

> обещало - это прерывание дернуло, а бит не выставило. Что делать?

с железкой разбираться.

да я понял, что для MFM винтов, а не для будущих антен.