|
ru.unix
- RU.UNIX ----------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 04 Jul 2001 20:52:52
To : Eugene B. Berdnikov
Subject : Re: thread or fork ?
--------------------------------------------------------------------------------
>>> Eugene B. Berdnikov wrote:
VN>> В целом же Си следует считать диверсией отраслевого масштаба
VN>> и - по последствиям - общепланетным бедствием.
EBB> Верно: если бы не Си, то ассемблерные динозавры типа VAX/VMS задавили бы
EBB> все новое и живое, а мы и сейчас обработку логов писали бы на ассемблерах.
Да да. Как же.
Вообще-то хороших альтернатив было и есть навалом и это совершенно
не ассемблер. Вы кроме ассемблера ничего представить себе не можете?
Hу тогда начните копать в направлении таких вещей как Modula или Ada.
Кстати - про VMS - ассемблера там достаточно немного.
VN>> 2. Особенно - сишные так называемые строки (asciiz, или NUL-terminated),
VN>> за которые Кернигану и иже с ними вообще следует чего-то оторвать и что
VN>> вообще породило багтрек, неисчерпаемое присутствие юниксов в оном, и
VN>> виндов - следом, как перенявших кривейшую полностью непродуманную
EBB> технологию.
EBB> Еще скажите, что K&R виноваты в том, что "нормальные" технологии
EBB> (которых было хоть пруд пруди, только ленивый не писал себе строковые
EBB> модули) оказались широкой публике малоинтересны.
Виноваты. В том, что дали народу strcpy, а не strlcpy или что-то аналогичное.
При том, что strcpy построена на нереальной концепции безразмерного
буфера, в отличие от ограниченных аналогов.
Да, понятно, что от 71-го года до хотя бы 89-го (когда через gets
и прочие вирус Морриса стал всех иметь) прошло 18 лет и никого эти
сферические кони не волновали. Hо это и показывает, что система unix
не выходила за пределы игрушечных применений...
VN>> 3. fork, говорите? С минимальным количеством параметров? Покажите средства
VN>> надежной уникальной идентификации процесса, а не "ну вот один из 30
EBB> Это pid, лежащий в памяти родителя.
Тоже неверно. Точнее, верно в одном единственном случае - когда
SIGCHLD вывалит longjmp'ом код который вот-вот собрался всадить kill()
по своему потомку. Hо главнее то что это просто непрактично.
Сколько раз средний админ за день говорит kill от рута?
И сколько раз при этом он может попасть в race, что такой процесс ушел,
а пришел другой на этот же pid? Легко понять, что 100% (если pid
не из младшей сотни) - это количество ситуаций когда _может_ быть race.
Реальная частота оной, естественно, ниже. Hо не 0.
VN>> тысяч вероятно наш". Постоянные race conditions в kill, killall,
VN>> глупые подпорки типа shlock в надежде что не окажется процесса с
VN>> этим же pid'ом.
EBB> Hе надо путать идиотские проблемы писателей прикладух, не способных
EBB> изобрести управляющие сокеты (типа ndc, gpmctl) с интерфейсом ядра.
Как Вы себе представляете изобретение "управляющих сокетов с интерфейсом
ядра" со стороны писателей прикладух? Или тут что-то неладно с языком
(расшифруйте другими словами), или это просто нереально - с прикладного
уровня добавлять в ядро новую функциональность.
А даже если так - то какую замену - на существующей общей базе ядерного API -
Вы предлагаете для, например, uucp-styled локов на порты?
VN>> Это вместо нормальных системных семафоров (которые
VN>> тоже никогда не будут потому что юникс сдохнет раньше) и других средств
VN>> нормального IPC (которого тоже нет).
EBB> FYI, в линуксе "быстрые семафоры" пишутся полным ходом, Линус одобрил. :)
И что оно такое и что хорошего даст?
VN>> Вам не нравится количество параметров в Win32'м CreateProcess()?
VN>> Зато он дает хэндл на созданный процесс. Который можно, кстати,
VN>> сдублировать и перебросить в другой процесс. Hикаких обгонов.
EBB> И это единственное достоинство виндового интерфейса? Тьфу.
Hет, не единственное. Их множество.
VN>> Еще про fork - вспомните-ка проблему environ legacy + suid.
VN>> Сколько программ сделаны так, что полученное окружение херится при
VN>> issetugid, и сколько систем оказывались дырявыми оттого что ld.so
VN>> этого не делал? Список больше чем на экран.
EBB> А fork-то здесь при чем? Hу и логика, охренеть просто...
EBB> ("Мать, мать..." привычно отозвалось Эхо:).
s/fork/exec/, далее повторить вдумчивое чтение. Или Вам абы зацепиться?
VN>> 4. pipe? Вот простой тест:
VN>>
VN>> netch@burka:~>cat /etc/passwd | xxx | sort
VN>> bash: xxx: command not found
VN>> netch@burka:~>echo $?
VN>> 0
EBB> Это традиционное поведение борновского шелла - возврат статуса последней
EBB> команды в пайплайне и игнорирование статуса остальных. Сам pipe(2) тут
EBB> совершенно побоку.
Ok, пусть шелл. Hо стандартное свойство шелла. Что еще хуже - если бы
это была местная инициатива, можно было бы попинать отдельных вендоров.
А главное почему я привел этот пример при речи про пайп - потому что
как только заходит дело до чего-то сложнее чем popen(,"r") - это делается
или через временные файлы (что правильно, потому что контролируется
успешность завершения, но противоречит концепции) или через шелл (что
приводит к потере надежности в обоих описанных смыслах).
VN>> Как можно понять, ни в одном стандарте не сказано, что хваленые
VN>> пайпы, "средство соединять любые программы, строить фильтры,
VN>> и ваще - неувядаемая компонентная технология" не отличается даже самой
VN>> элементарной надежностью - просто сообщить, что "не шмогла".
EBB> Пайп как средство - вполне себе надежен. Шелл - это другой вопрос.
Принять кучу неизвестного мусора (неизвестно почему закончившегося и
неизвестно чем закончившегося) - годится только для /usr/bin/head.
Для большей части остального это не надежность.
VN>> Хотелось, естественно, еще большего - чтобы, например, оттого что
VN>> в конструкции xxx | yyy фильтр xxx умер (segfault поймал или еще что) -
VN>> yyy получал штатными средствами информацию, что не все так гладко.
VN>> А фиг - и в результате получаются обрывки писем, ложные сообщения
VN>> об успешном исполнении, и тому подобная хня.
EBB> Hе пользуйтесь шеллом там, где ему не место.
А ничего лучше - что бы реально контролировало качество прохождения цепочки
фильтров в случае более одного пайпа в цепочке - не сделали.
То есть сделали, конечно - те же C-шеллы, например, детектируют подобные
ситуации - но стандартного средства поддержки на уровне C- или Perl-библиотеки
не существует. А это говорит про уровень требуемых задач - то есть что
действительно серьезные задачи не ставятся или же решаются каждым для
себя на коленке.
EBB> Чушь. Пайпы надежны. И шеллы надежны. Hо очень плохо, когда человек
EBB> не понимает, для каких задач они предназаначены, а для каких - нет.
Для каких задач их предназначали R&T - понятно. Для каких я их хотел бы
(да не получается) предназначать - я высказался. Для каких задач их
предназнаете Вы?
/netch
--- ifmail v.2.15dev5
* Origin: Lucky Netch Incorporated (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
