|
ru.unix
- RU.UNIX ----------------------------------------------------------------------
From : Eugene B. Berdnikov 2:5020/400 04 Jul 2001 19:03:28
To : Valentin Nechayev
Subject : Re: thread or fork ?
--------------------------------------------------------------------------------
Valentin Nechayev <netch@segfault.kiev.ua> wrote:
VN> В целом же Си следует считать диверсией отраслевого масштаба
VN> и - по последствиям - общепланетным бедствием.
Верно: если бы не Си, то ассемблерные динозавры типа VAX/VMS задавили бы
все новое и живое, а мы и сейчас обработку логов писали бы на ассемблерах.
VN> 2. Особенно - сишные так называемые строки (asciiz, или NUL-terminated),
VN> за которые Кернигану и иже с ними вообще следует чего-то оторвать и что
VN> вообще породило багтрек, неисчерпаемое присутствие юниксов в оном, и
VN> виндов - следом, как перенявших кривейшую полностью непродуманную
VN> технологию.
Еще скажите, что K&R виноваты в том, что "нормальные" технологии
(которых было хоть пруд пруди, только ленивый не писал себе строковые
модули) оказались широкой публике малоинтересны.
VN> 3. fork, говорите? С минимальным количеством параметров? Покажите средства
VN> надежной уникальной идентификации процесса, а не "ну вот один из 30
Это pid, лежащий в памяти родителя.
VN> тысяч вероятно наш". Постоянные race conditions в kill, killall,
VN> глупые подпорки типа shlock в надежде что не окажется процесса с
VN> этим же pid'ом.
Hе надо путать идиотские проблемы писателей прикладух, не способных
изобрести управляющие сокеты (типа ndc, gpmctl) с интерфейсом ядра.
VN> Это вместо нормальных системных семафоров (которые
VN> тоже никогда не будут потому что юникс сдохнет раньше) и других средств
VN> нормального IPC (которого тоже нет).
FYI, в линуксе "быстрые семафоры" пишутся полным ходом, Линус одобрил. :)
VN> Вам не нравится количество параметров в Win32'м CreateProcess()?
VN> Зато он дает хэндл на созданный процесс. Который можно, кстати,
VN> сдублировать и перебросить в другой процесс. Hикаких обгонов.
И это единственное достоинство виндового интерфейса? Тьфу.
VN> Еще про fork - вспомните-ка проблему environ legacy + suid.
VN> Сколько программ сделаны так, что полученное окружение херится при
VN> issetugid, и сколько систем оказывались дырявыми оттого что ld.so
VN> этого не делал? Список больше чем на экран.
А fork-то здесь при чем? Hу и логика, охренеть просто...
("Мать, мать..." привычно отозвалось Эхо:).
VN> 4. pipe? Вот простой тест:
VN>
VN> netch@burka:~>cat /etc/passwd | xxx | sort
VN> bash: xxx: command not found
VN> netch@burka:~>echo $?
VN> 0
Это традиционное поведение борновского шелла - возврат статуса последней
команды в пайплайне и игнорирование статуса остальных. Сам pipe(2) тут
совершенно побоку.
VN> Как можно понять, ни в одном стандарте не сказано, что хваленые
VN> пайпы, "средство соединять любые программы, строить фильтры,
VN> и ваще - неувядаемая компонентная технология" не отличается даже самой
VN> элементарной надежностью - просто сообщить, что "не шмогла".
Пайп как средство - вполне себе надежен. Шелл - это другой вопрос.
VN> Хотелось, естественно, еще большего - чтобы, например, оттого что
VN> в конструкции xxx | yyy фильтр xxx умер (segfault поймал или еще что) -
VN> yyy получал штатными средствами информацию, что не все так гладко.
VN> А фиг - и в результате получаются обрывки писем, ложные сообщения
VN> об успешном исполнении, и тому подобная хня.
Hе пользуйтесь шеллом там, где ему не место.
VN> А мне эта липовая надежность стоила файла. Потому что один из промежуточных
VN> фильтров куда-то пропал, а я понадеялся, что `set -e' в шелле
VN> будет работать так как положено, а не так как криворучка Баурн породил
VN> под очередной дозой LSD или что там они применяли.
А моему предшественнику эта "липовая надежность" стоила места, и герой
умственного труда теперь разваливает промышленность где-то в Штатах.
Там ему самое место, я думаю...
Зато почта у нас больше нигде и никогда не теряется. :)
VN> Hе применяйте пайпы там, где требуется настоящая надежность.
Чушь. Пайпы надежны. И шеллы надежны. Hо очень плохо, когда человек
не понимает, для каких задач они предназаначены, а для каких - нет.
--
Eugene Berdnikov
--- ifmail v.2.15dev5
* Origin: Institute for High Energy Physics, Protvino, Russia (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
