Здравствуйте Slov, Вы писали:
S>Здравствуйте Zlobec, Вы писали:
S>>>А так чтоб в сети и бесплатно? Да еще желательно покорече, а не целая книга? Ах, да, и еще по русски Z>>И еще чтоб сама говорила!
S>Ага! При выключенном компьютере, по ночам, загробным голосом из системного блока будут даносится звуки и исходить голубое свечение. Только нужно предварительно голову жареного пингвина на процессор положить?..
Ага причем пингвин должен покончить жисть самоубийством выбросившись из окна.
Здравствуйте Slov, Вы писали:
S>Скажу сразу, в *nix я понимаю немного. S>При прочтении очередной перепалки Apache on Win32 vs Apache on *nix наткнулся на утверждение что в винде хуже реализованы потоки и изоляция процессов. Это несколько не вяжется с тем что я помню, но ... см. выше Так что вопрос — так ли это? А еще было бы интересно почитать краткий обзор устройства ядра *nix системы и как там все организовано.
Читайте Робачевский Операционная система UNIX
Скажу сразу, в *nix я понимаю немного.
При прочтении очередной перепалки Apache on Win32 vs Apache on *nix наткнулся на утверждение что в винде хуже реализованы потоки и изоляция процессов. Это несколько не вяжется с тем что я помню, но ... см. выше Так что вопрос — так ли это? А еще было бы интересно почитать краткий обзор устройства ядра *nix системы и как там все организовано.
Здравствуйте Slov, Вы писали:
S>Скажу сразу, в *nix я понимаю немного. S>При прочтении очередной перепалки Apache on Win32 vs Apache on *nix наткнулся на утверждение что в винде хуже реализованы потоки и изоляция процессов. Это несколько не вяжется с тем что я помню, но ... см. выше Так что вопрос — так ли это? А еще было бы интересно почитать краткий обзор устройства ядра *nix системы и как там все организовано.
насколько я знаю, в юниксах вообще нет понятия "поток", там только "процессы". в терминах форточек получается, что каждый процесс обладает одним и только одним потоком.
Здравствуйте neutrino, Вы писали:
N>Здравствуйте Slov, Вы писали:
S>>Скажу сразу, в *nix я понимаю немного. S>>При прочтении очередной перепалки Apache on Win32 vs Apache on *nix наткнулся на утверждение что в винде хуже реализованы потоки и изоляция процессов. Это несколько не вяжется с тем что я помню, но ... см. выше Так что вопрос — так ли это? А еще было бы интересно почитать краткий обзор устройства ядра *nix системы и как там все организовано.
N>насколько я знаю, в юниксах вообще нет понятия "поток", там только "процессы". в терминах форточек получается, что каждый процесс обладает одним и только одним потоком.
В юниках есть такое понятие "нить" (thread).Но реализация зависит от конкретного ядра. Она точна естьв солярке. Для линуха имхо их штуки три реализации. Есть ли в BSDя не знаю
Здравствуйте Zlobec, Вы писали:
Z>В юниках есть такое понятие "нить" (thread).Но реализация зависит от конкретного ядра. Она точна естьв солярке. Для линуха имхо их штуки три реализации. Есть ли в BSDя не знаю
про thread-ы я и говорю. а ты может быть имеешь ввиду расширение PTHREADS?
Здравствуйте neutrino, Вы писали:
N>Здравствуйте Zlobec, Вы писали:
Z>>В юниках есть такое понятие "нить" (thread).Но реализация зависит от конкретного ядра. Она точна естьв солярке. Для линуха имхо их штуки три реализации. Есть ли в BSDя не знаю
N>про thread-ы я и говорю. а ты может быть имеешь ввиду расширение PTHREADS?
И их тоже.
Здравствуйте neutrino, Вы писали:
N>насколько я знаю, в юниксах вообще нет понятия "поток", там только "процессы". в терминах форточек получается, что каждый процесс обладает одним и только одним потоком.
Уже давно есть, даже уже в posix стандарт включено все.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте Anatolix, Вы писали:
A>Здравствуйте neutrino, Вы писали:
N>>насколько я знаю, в юниксах вообще нет понятия "поток", там только "процессы". в терминах форточек получается, что каждый процесс обладает одним и только одним потоком.
A>Уже давно есть, даже уже в posix стандарт включено все.
Ладно, с нитками разобрались. То что существует несколько сторонних реализаций, это я и так знал... Меня как раз больше интересует вопрос про изоляцию процессов. Как это организовано в юниксах?
Здравствуйте Slov, Вы писали:
S>Здравствуйте Zlobec, Вы писали:
Z>>Читайте Робачевский Операционная система UNIX
S>А так чтоб в сети и бесплатно? Да еще желательно покорече, а не целая книга? Ах, да, и еще по русски
И еще чтоб сама говорила!
Здравствуйте Zlobec, Вы писали:
S>>А так чтоб в сети и бесплатно? Да еще желательно покорече, а не целая книга? Ах, да, и еще по русски Z>И еще чтоб сама говорила!
Ага! При выключенном компьютере, по ночам, загробным голосом из системного блока будут даносится звуки и исходить голубое свечение. Только нужно предварительно голову жареного пингвина на процессор положить?..
Здравствуйте Slov, Вы писали:
S>Здравствуйте Anatolix, Вы писали:
A>>Здравствуйте neutrino, Вы писали:
N>>>насколько я знаю, в юниксах вообще нет понятия "поток", там только "процессы". в терминах форточек получается, что каждый процесс обладает одним и только одним потоком.
В юниксах давно есть и то и другое!
например:
Apache — мультипроцессоный веб-сервер(в памяти размножается посредством fork()),
а MySQL — мультипоточный(multithreaded) сервер БД.
A>>Уже давно есть, даже уже в posix стандарт включено все.
S>Ладно, с нитками разобрались. То что существует несколько сторонних реализаций, это я и так знал... Меня как раз больше интересует вопрос про изоляцию процессов. Как это организовано в юниксах?
В разных юниксах по-разному.
И вообще, изоляция процессов — вопрос довольно общий и неконкретный.
Здравствуйте DSD, Вы писали:
S>>Ладно, с нитками разобрались. То что существует несколько сторонних реализаций, это я и так знал... Меня как раз больше интересует вопрос про изоляцию процессов. Как это организовано в юниксах?
DSD>В разных юниксах по-разному. DSD>И вообще, изоляция процессов — вопрос довольно общий и неконкретный.
Хорошо, конкретизируем. Из одного процесса я могу например читать память: любого другого процесса в ОС, только процессов этого пользователя, только текущего процесса, каких-то конкретных процессов — нужное подчеркнуть Желательно с указанием в каких юниксах.
Здравствуйте Slov, Вы писали:
S>Здравствуйте DSD, Вы писали:
S>>>Ладно, с нитками разобрались. То что существует несколько сторонних реализаций, это я и так знал... Меня как раз больше интересует вопрос про изоляцию процессов. Как это организовано в юниксах?
DSD>>В разных юниксах по-разному. DSD>>И вообще, изоляция процессов — вопрос довольно общий и неконкретный.
S>Хорошо, конкретизируем. Из одного процесса я могу например читать память: любого другого процесса в ОС, только процессов этого пользователя, только текущего процесса, каких-то конкретных процессов — нужное подчеркнуть Желательно с указанием в каких юниксах.
Нет, просто так читать память произвольных процессов кроме текущего ты не можешь, даже родственных процессов.
Однако если тебе это нужно для обмена данными между твоими процессами/программами, то
для этого существуют специальные средства.
Эти средства имеют общее название — IPC (Inter-Process Communication)
Сюда входят такие вещи, как:
— разделение памяти (Shared Memory)
— трубы, сокеты и т.п. (Pipes, Sockets)
— удаленные процедуры и двери (RPC, Doors)
— ну и еще несколько примочек, я их все щас не помню
В частности к твоему вопросу относится пожалуй только разделение памяти.
Оно может быть реализовано как на уровне ОЗУ, так и на уровне файловой системы.
В общем случае все сводится к отображению одного и того же участка памяти(или файла) по произвольному поинтеру в локальный стек переменных одного или нескольких процессов.
Тут тоже можно долго рассказывать об этом всем, поэтому если что-то интересует конкретно, спрашивай.
Далее, по поводу работы нитей(threads) и создания дочерних процессов:
С нитями все довольно просто. Глобальные переменные расшариваются между нитями одного процесса, локальные в каждой нити — нет.
При создании дочернего процесса грубо говоря родительский процесс просто дублируется в памяти.
Если сказать более точно о ресурсах, то дублируется только стек переменных, а скажем, открытые соединения(сокеты) не дублируются, дублируются только ссылки на них. С Shared Memory и открытыми файлами — то же самое.
В некоторых системах есть некоторые особенности копирования процессов: так,
например, в FreeBSD присутствует технология CopyOnWrite. Она подразумевает под
собой копирование области ресурсов процесса не сразу, а только, когда процесс-родитель или
процесс-ребенок пытается изменить эти данные в своем стеке.
Во многих случаях это экономит ОЗУ, так как далеко не каждая задача после отсоединения
по fork() и до своего завершения нуждается в большинстве переменных родителя.
DSD>Нет, просто так читать память произвольных процессов кроме текущего ты не можешь, даже родственных процессов. DSD>Однако если тебе это нужно для обмена данными между твоими процессами/программами, то DSD>для этого существуют специальные средства. DSD>Эти средства имеют общее название — IPC (Inter-Process Communication)
DSD>Сюда входят такие вещи, как: DSD> — разделение памяти (Shared Memory) DSD> — трубы, сокеты и т.п. (Pipes, Sockets) DSD> — удаленные процедуры и двери (RPC, Doors) DSD> — ну и еще несколько примочек, я их все щас не помню
DSD>В частности к твоему вопросу относится пожалуй только разделение памяти. DSD>Оно может быть реализовано как на уровне ОЗУ, так и на уровне файловой системы. DSD>В общем случае все сводится к отображению одного и того же участка памяти(или файла) по произвольному поинтеру в локальный стек переменных одного или нескольких процессов. DSD>Тут тоже можно долго рассказывать об этом всем, поэтому если что-то интересует конкретно, спрашивай.
Это куда более развернутый ответ, но опять, ничего нового для себя я не узнал Мне кажется что я изначально верно сформулировал вопрос, но ответа на него я так и не получил А именно — фраза "наткнулся на утверждение что в винде хуже реализованы потоки и изоляция процессов". Т.е. я хочу знать в чем именно изоляция процессов в юникс лучше чем в винде (прод виндой я понимаю W2K+)? Это не с целью разжечь священную войну (да и врядли она получится на RSDN), я и правда хочу знать, т.к. стараюсь, как говорится, знать немножко обо всем
S>"наткнулся на утверждение что в винде хуже реализованы потоки и изоляция процессов"
Вот на это конкретно ответить я пожалуй и не смогу
сам то же самое слышал, но конкретных "разжеванных" примеров и обоснований не встречал.
Знаю только, что архитектура юниксов изначально была рассчитана на многозадачность и серверные решения,
а винда, как мы помним, выросла из надстройки над ДОСом, да и рассчитана она больше на клиентский интерфейс...
Но факт остается фактом — при одной и той же аппаратной мощности сервер под *nix работает заметно быстрее, чем под Win.
Вот так-то..
P.S. А священную войну не из чего разводить вообще, так как давно ясно, что сервера лучше всего строить на юниксах, а клиенты и интерфейсную часть надо писать под винды.
Мое личное мнение:
Винды как сервер — отстой,
а GUI в *nix — еще больший отстой
Здравствуйте DSD, Вы писали:
DSD>Здравствуйте Slov, Вы писали:
DSD> S>>"наткнулся на утверждение что в винде хуже реализованы потоки и изоляция процессов"
DSD>Вот на это конкретно ответить я пожалуй и не смогу DSD>сам то же самое слышал, но конкретных "разжеванных" примеров и обоснований не встречал.
[Скип]
Эх, лучше б ты просто ответил что не знаешь... Все же остальные рассуждения в твоем ответе о сервернутости или клиентрутости разных систем являются сугубо твоим личным мнением и информационной ценности не представляют. Я доверяю только фактам и аргументированным объяснениям. Каждая система (не только *nix || Win*) имеет ряд особенностей которые в каждой конкретной ситуации могут быть как достоинствами так и недостатками. Думаю ты не станешь спорить что бывают ситуации, когда TR-DOS предпочтительнее навороченного IRIX? Эти особенности нужно просто знать (чего я и добивался), чтобы делать свой выбор в каждой ситуации. А фразы о том кто от кого произошел и кто на что был рассчитан — это просто заявления. Они не позволяют нам сделать выводы о качественных/количественных характеристиках системы и только сбивают с толку.
А вообще тем что всякие handle в windows видны изо всех процессов, а не только из тех кто их создал.
Кроме того возможны всякие дикие хаки типа WindowsHooks или API Hooks итп
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте Anatolix, Вы писали:
A>Т.е. я хочу знать в чем именно изоляция процессов в юникс лучше чем в винде (прод виндой я понимаю W2K+)?
Короче, я уже сам разобрался откуда у этого заявления ноги росли. Это было из-за разности в скорости выполнения fork vs. CreateProcess, которая собственно возникает из-за упрощенной изоляции процессов в юникс, а не наоборот.
A>Ну например вот: A>http://rsdn.ru/forum/?mid=116642
А с какого боку тут изоляция процессов?
A>А вообще тем что всякие handle в windows видны изо всех процессов, а не только из тех кто их создал.
1. не всегда, 2 — проблем с защитой это не вызывает, даже наоборот, 3 — ну да, в юникс вообще хендлов нет, соотв. видеть нечего...
A>Кроме того возможны всякие дикие хаки типа WindowsHooks или API Hooks итп
опять же — при чем тут изоляция процессов и чем это плохо — не понятно...
Ладно, это все не важно. Чтоб успокоить возможные возражения, сразу скажу, что я действительно считаю юникс более удачной платформой для серверов чем Win ... благодяря их простоте и прямолинейности, что для сервера оказывается довольно полезным качеством.
S>А с какого боку тут изоляция процессов?
S>опять же — при чем тут изоляция процессов и чем это плохо — не понятно...
Объясни мне что в твоем понимании изоляция процессов? В моем понимании это когда один процесс не может по случайности или злому умыслу сломать другой процесс. В Windows это возможно, в unix нет.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
S>>А с какого боку тут изоляция процессов?
S>>опять же — при чем тут изоляция процессов и чем это плохо — не понятно...
A>Объясни мне что в твоем понимании изоляция процессов? В моем понимании это когда один процесс не может по случайности или злому умыслу сломать другой процесс. В Windows это возможно, в unix нет.
Да, именно это. Так расскажи как это возможно в Windows? Нет, возможно конечно, имея необходимые права. Например имея право отладки я могу вскрытвать другие процессы. Только чем это плохо? Нужно ведь просто не давать такие права кому не надо? Есть еще что-то о чем я не знаю? Правда мы так уйдем в оффтопик...
Здравствуйте Slov, Вы писали:
S>Да, именно это. Так расскажи как это возможно в Windows? Нет, возможно конечно, имея необходимые права. Например имея право отладки я могу вскрытвать другие процессы. Только чем это плохо? Нужно ведь просто не давать такие права кому не надо? Есть еще что-то о чем я не знаю? Правда мы так уйдем в оффтопик...
Да запросто. Ты понимаешь что в Windows можно послать Любое сообщение, Любому окну вне зависимости от привилегий процесса. Некоторые сообщения в частности WM_TIMER заставляют программу делать неожиданные действия и тп. Некоторые (WM_CLOSE) заставляют внутренние объекты программы уничтожаться и тп
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте Anatolix, Вы писали:
S>>Да, именно это. Так расскажи как это возможно в Windows? Нет, возможно конечно, имея необходимые права. Например имея право отладки я могу вскрытвать другие процессы. Только чем это плохо? Нужно ведь просто не давать такие права кому не надо? Есть еще что-то о чем я не знаю? Правда мы так уйдем в оффтопик...
A>Да запросто. Ты понимаешь что в Windows можно послать Любое сообщение, Любому окну вне зависимости от привилегий процесса. Некоторые сообщения в частности WM_TIMER заставляют программу делать неожиданные действия и тп. Некоторые (WM_CLOSE) заставляют внутренние объекты программы уничтожаться и тп
Ты же сам в том топике дал ответ относительно того что это не проблема ОС, а уязвимость конкретных сервисов. К тому же в MSDN на этот счет даны четкие указания, что так писать нельзя. И на последок, я не понимаю с чего бы вдруг оконная подсистема сообщений относилась к изоляции процессов. Что, в Windows все процессы посылают/принимают сообшения? Так что никакого нарушения изоляции я не вижу. Еще варианты?
Здравствуйте Slov, Вы писали:
S>Ты же сам в том топике дал ответ относительно того что это не проблема ОС, а уязвимость конкретных сервисов.
Угу. Перекладываение с больной головы но здоровую.
> К тому же в MSDN на этот счет даны четкие указания, что так писать нельзя.
Угу, нет ничего страшного в минах на футбольном поле если футболистам сказано что на них наступать нельзя.
> И на последок, я не понимаю с чего бы вдруг оконная подсистема сообщений относилась к изоляции процессов.
Тогда дай твое определение изоляции процессов. Потому что ответ на твой вопрос просто не имеет смысла. Тебе дают ответ а ты говоришь "меня вообще не это интересует и это совсем не то, и вообще это не изоляция".
Ты согласился с моим определением что плохая изоляция это возможность сломать другой процесс, так вот я могу сломать почти любой процесс заставив его перейти по несуществующему адресу с помощью WM_TIMER после чего в нем будет Access Violation и он будет закрыт. Прав мне никаких для этого не надо.
Если ты имел ввиду что то другое то задай свой вопрос ПРАВИЛЬНО.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте Anatolix, Вы писали:
S>>Ты же сам в том топике дал ответ относительно того что это не проблема ОС, а уязвимость конкретных сервисов.
A>Угу. Перекладываение с больной головы но здоровую.
>> К тому же в MSDN на этот счет даны четкие указания, что так писать нельзя.
A>Угу, нет ничего страшного в минах на футбольном поле если футболистам сказано что на них наступать нельзя.
Тут ты не парв. Когда речь идет о пользователях, тогда да, но сейчас речь идет о программистах. Про buffer overflow все знают. Тут никакая ОС не поможет. Так чтоОС в которой будет безопасно программировать — это конечно круто, но пока нереально (разве что Java, но она не ОС
>> И на последок, я не понимаю с чего бы вдруг оконная подсистема сообщений относилась к изоляции процессов.
A>Тогда дай твое определение изоляции процессов. Потому что ответ на твой вопрос просто не имеет смысла. Тебе дают ответ а ты говоришь "меня вообще не это интересует и это совсем не то, и вообще это не изоляция".
A>Ты согласился с моим определением что плохая изоляция это возможность сломать другой процесс, так вот я могу сломать почти любой процесс заставив его перейти по несуществующему адресу с помощью WM_TIMER после чего в нем будет Access Violation и он будет закрыт. Прав мне никаких для этого не надо.
A>Если ты имел ввиду что то другое то задай свой вопрос ПРАВИЛЬНО.
А вот тут я с тобой почти согласен. Почти, потому что ты можешь вызвать Access Violation в любом потоке, который имеет окна в твоей Window Station (WinSta0) и использует дефолтную обработку WM_TIMER. Для большинства пользовательских прикладных процессов это значит что ты можешь их прибить. Но ведь ты и так можешь их прибить Хотя с утверждением что некоторое нарушение изоляции существует я полностью согласен.
Кстати, а как это реализовано например в XWindow?
Здравствуйте Slov, Вы писали:
S>Тут ты не парв. Когда речь идет о пользователях, тогда да, но сейчас речь идет о программистах. Про buffer overflow все знают. Тут никакая ОС не поможет. Так чтоОС в которой будет безопасно программировать — это конечно круто, но пока нереально (разве что Java, но она не ОС
Buffer Overflow это классическая ошибка программиста. Выделил недостаточный размер буфера получи. Но нельзя же заставлять программера переопределять все обработчики у всех окон.
S>Кстати, а как это реализовано например в XWindow?
Не в курсе к сожалению. Но вообще сильно сомневаюсь что там можно получить доступ к чужому окну.
В Windows это существует только потому что все привыкли это делать с Win16.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Желательно с указанием в каких юниксах. 
Мне кажется что я изначально верно сформулировал вопрос, но ответа на него я так и не получил 