= RU.UNIX (2:5005/14.1) ============================================= RU.UNIX = Msg : 8 of 296 -3 +16 Scn From : Valentin Nechayev 2:5020/400 Wed 21 Aug 02 10:16 To : Vasily Korytov Wed 21 Aug 02 14:01 Subj : Re: зависший процесс =============================================================================== From: Valentin Nechayev >>> Vasily Korytov wrote: VN>> Hепрерываемость дискового и NFS'ного sleep - одна из грубейших ошибок VN>> проектирования unix'ов. VK> Пожалуйста, расскажи, почему ты так считаешь. Для меня это неочевидно. Тут скорее даже не непрерываемость, а ее причина - идиотское построение работы с драйверами. Hе предусмотрены: 1) асинхронная отработка запроса (хотя в канонической староюниксовой архитектуре против нее нет никаких возражений - и IPL'и можно ставить как угодно, и completion вызвать, и wakeup дернуть, и никто тебе не сделает schedule в самый ответственный момент, и запускать kernel-only процессы для устойчивой обработки на уровне softinterrupt никто не мешает); 2) отмена запроса к драйверу. При том, что все это уже было давно - вспомнить хотя бы RT-11, RSX-11 и иже с ними. В книге по Инмос есть забавное замечание - мол, архитектурный запрет переключения процессов, находящихся в системной фазе, - решение действенное, но слишком грубое (например, не дает жить нормальному realtime). Оно показывает, что более тонкие решения давно уже существовали и были неплохо известны. В то же время в первых юниксах - был полный бардак. Сделать ожидание ввода по времени - нереально. O_NONBLOCK во всех видах - отсутствует, select - отсутствует, AIO - отсутствует, сигналом можно только срубить процесс и ничего более (обработчики неустойчивы, какое-то улучшение наступило только когда BSD и ATT параллельно друг другу начали делать reliable signals - а это не только sigprocmask и sigaction, а и вообще изменение метода реакции ядра на сигналы, включая sleep и sysentry). Даже подождать пару минут ввода с консоли и потом сказать "оп-па, ваше время истекло" было нереально. Когда вводили неблокирующий режим и прерывание сигналом, его ввели для тех операций, которые заведомо могли иметь неограниченный по длительности характер - тот же read с терминала или из пайпа. Hо для диска было решено, что ну его нафиг, bio layer менять - себе дороже, и лучше мы в star trek поиграем. А потом пришел NFS. Который и BIO, и в то же время сетевой. А системы устойчивостью не отличаются - они и сейчас не слишком устойчивы, а тогда - тем более. А потом все чаще стало оказываться, что надо сохранять жизнь запущенной системы несмотря на местные сбои, и оказалось, что VFS совершенно не понимает невозможность работы с диском (позы с panic при записи на защищенную от записи дискету многие помнят), umount насильный невозможен - хотя почти вся работа там подставить на все vnode фиктивные VMT и отцепить буфера запрошенных операций - ан нет, базовая идея что с диском проблем у нас не бывает и что BIO всегда выполняет свои действия точно и в срок - проникла всюду. Что и дает нынешнее убогое состояние. Ты сейчас просто не представляешь себе, каким дерьмом был unix раньше и как его из этого состояния вытаскивали за уши. В первых sh даже cd был внешней программой - сейчас кому-то сказать, кто знает про сисколл chdir(), но не знает истории, даст приступ истерического смеха. Эта команда лезла в память своего родителя и там меняла текущий каталог. А для этого ей еще надо было загрузиться с диска (кэша никакого кроме как на 15 блоков включая суперблоки - не было...) То, что сейчас видим - результат того, что народ взял то, что было доступно - эту совершенно непригодную для промышленной работы систему - и начал ее доводить, потому что это было дешевле, чем писать с нуля или покупать серьезные системы. А в результате имеем то что имеем - под слоем новой красивой краски выглядывают слои плохо замазанной ржавчины... /netch --- ifmail v.2.15dev5 * Origin: Dark side of coredump (2:5020/400)