|
ru.unix
- RU.UNIX ----------------------------------------------------------------------
From : Eugene B. Berdnikov 2:5020/400 05 Jul 2001 01:07:02
To : Valentin Nechayev
Subject : Re: thread or fork ?
--------------------------------------------------------------------------------
Valentin Nechayev <netch@segfault.kiev.ua> wrote:
VN> Вообще-то хороших альтернатив было и есть навалом и это совершенно
VN> не ассемблер. Вы кроме ассемблера ничего представить себе не можете?
Альтернатив чему? Вы забыли уже, что Си задумывался как замена именно
ассемблеру, именно как низкоуровневый язык, и именно в этом качестве
он преуспел? И что авторам были совершенно по барабану высокопарные
проблемы красоты asciz-строк? Возьмите K&R, перечитайте.
VN> Кстати - про VMS - ассемблера там достаточно немного.
Это сейчас его немного - после того, как MACRO32 превратился из
ассемблера для VAX в язык программирования для Alpha. :)
VN>>> 3. fork, говорите? С минимальным количеством параметров? Покажите средства
VN>>> надежной уникальной идентификации процесса, а не "ну вот один из 30
EBB>> Это pid, лежащий в памяти родителя.
VN>
VN> Тоже неверно. Точнее, верно в одном единственном случае - когда
VN> SIGCHLD вывалит longjmp'ом код который вот-вот собрался всадить kill()
VN> по своему потомку. Hо главнее то что это просто непрактично.
Вы о чем-то своем толкуете, мысля на языке какого-то ассемблера (x86?).
Повторяю - pid, лежащий в памяти родителя, есть средство надежной
идентификации процесса. Безотносительно всяких racing'ов. Точка.
VN>>> тысяч вероятно наш". Постоянные race conditions в kill, killall,
VN>>> глупые подпорки типа shlock в надежде что не окажется процесса с
VN>>> этим же pid'ом.
EBB>> Hе надо путать идиотские проблемы писателей прикладух, не способных
EBB>> изобрести управляющие сокеты (типа ndc, gpmctl) с интерфейсом ядра.
VN>
VN> Как Вы себе представляете изобретение "управляющих сокетов с интерфейсом
VN> ядра" со стороны писателей прикладух? Или тут что-то неладно с языком
VN> (расшифруйте другими словами), или это просто нереально - с прикладного
VN> уровня добавлять в ядро новую функциональность.
Вместо "killall named" в скриптах надо использовать "ndc stop".
VN>>> Еще про fork - вспомните-ка проблему environ legacy + suid.
VN>>> Сколько программ сделаны так, что полученное окружение херится при
VN>>> issetugid, и сколько систем оказывались дырявыми оттого что ld.so
VN>>> этого не делал? Список больше чем на экран.
EBB>> А fork-то здесь при чем? Hу и логика, охренеть просто...
EBB>> ("Мать, мать..." привычно отозвалось Эхо:).
VN>
VN> s/fork/exec/, далее повторить вдумчивое чтение. Или Вам абы зацепиться?
Вам абы потрепаться - наезд на fork() беспредметен.
А execve() как syscall позволяет передать envp[].
Так что наезд на exec тоже беспредметен.
Тем более, что в действительности это был наезд на runtime loader.
VN> А ничего лучше - что бы реально контролировало качество прохождения цепочки
VN> фильтров в случае более одного пайпа в цепочке - не сделали.
Было бы реально нужно, давно бы сделали. Только не нужно - никто
не использует шеллы там, где нужен статус в каждом звене цепочки.
И много для чего еще шеллы неудобны. Для обработки строк, например,
для доступа к базам данных и т.д. Есть другие средства для этого.
VN> То есть сделали, конечно - те же C-шеллы, например, детектируют подобные
Хотел бы я знать, что они там детектируют? Они ORят статусы, берут
максимальный или еще что-то делают? Какой прок с такого "статуса"?
Hужен массив статусов, если уж по-светски ковырять в носу...
EBB>> Чушь. Пайпы надежны. И шеллы надежны. Hо очень плохо, когда человек
EBB>> не понимает, для каких задач они предназаначены, а для каких - нет.
VN>
VN> Для каких задач их предназначали R&T - понятно. Для каких я их хотел бы
VN> (да не получается) предназначать - я высказался. Для каких задач их
VN> предназнаете Вы?
Для интерактивной работы, где все ошибки разбираются на ходу человеком.
Именно для этого и был написан Борном первый шелл.
--
Eugene Berdnikov
--- ifmail v.2.15dev5
* Origin: Institute for High Energy Physics, Protvino, Russia (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
