Что-то совсем всё смешалось в кучу - кони, люди. Причем вообще форк к клиентам? Клиент обращается к сокету, а кто его открыл - папаша, или сынок - без разницы. Ну есть у тебя в новом процессе файловые дескрипторы папаши и ты их можешь слушать. Ну на винде у тебя в новом трэде абсолютно прозрачный доступ к открытому сокету, неважно кто его открывал. В чём выигрыш?

В винде ты когда создал новый трэд, он имеет тоже самое адрессное пространство что и другие трэды процесса и ты можешь имея глобальные ссылки использовать любой объект процесса, будь то сокет или файл. Кроме того можно шарить ресурсы между трэдами. В Юниксе при использовании форка ты работаешь с изолированными процессами. И для обмена данными приходится использовать пайпы и другие файлы, вместо того чтобы получить прямую ссылку на объект.



Если добавить управление пользователями и разграничение прав доступа, то да - серверная ось.

Апач работающий под виндой по твоему не сервер?   

Почитай про серверы хотя бы здесь   

VectorMan,  сервер - это предлагающий услугу.
Однако любая ось это способна делать. Просто некоторые предназначены для этого(никсы), а некоторые - нет(хм, пример приводили   )


 Для примера.


 Просил же треды не трогать =) Больная тема: пишу на пхп, а там тредов нет. Для многопоточности остаются тоько форк или асинхронные сокеты. Хотя это проблема пхп.


 О, уже появились эти "если". Хотя недавно ты сказал:
 Т.е. теперь от слов своих отказываешься? =)


 Мда.... а если я скажу, что потоки(треды) есть и в никсах? Это не будет новостью?



 Угу, это так. Заплатки на текущий момент нет. Более того, возможно поднятие прав на уровень системы.
Я думаю, что серверная ось не может не закрывать КРИТИЧЕСКИЕ  уязвимости на протяжении уже недели. И неизвестно, когда эта заплатка выйдет. Может через месяц?
Линк(хотя об уязвимости было известно еще до того, как секлаб это все размести): http://www.securitylab.ru/vulnerability/283245.php
Или кто-то не согласен, что выполнение произвольного кода с правами суперпользователя - не критическая уязвимость?

Добавлено @ 19:53 
 Слово сервер имелось в другом смысле. У него есть много смыслов, а не только сервис/демон.

Не будет. Но это уже не fork. К тому же трэды есть далеко не на всех Юниксах. Во FreeBSD, к примеру, их нет. Есть либы которые фактически эммулируют работу трэдов, но по сути это теже процессы.



Ну вобщем-то ПХП от оси не зависит. Это скриптовый язык, который и под виндой вполне нормально живет. Кроме того на хостингах вызов fork как правило запрещен, так что советую отвыкать   



Нет, просто расширяю вышесказанное. Ну забыл про разграничение прав доступа в предыдущем посте. А я вот до сих пор не пойму какой ты смысл вкладываешь в "серверную ось". Выскажи, и я тоже покритикую   




Хотелось бы услышать какие?   

Ещё раз извиняюсь за оффтоп, но потоки во FreeBSD есть.

Системный вызов rfork работает почти так же как fork, но дочерний процесс разделяет всю память с родительским, библиотека posix threads использует этот вызов

Но если посмотреть top, то он все эти трэды нарисует как процессы, каждый со своим PID. Изначально работа с трэдами туда не вкладывалась. 

 А я и не говорил, что это форк.

 Хм, ненавижу фряху, у меня на серваке ее в ближайшем будущем точно не будет ;)
По крайней мере в OpenBSD треды точно есть   

 Неправда.
Зависит, так как большинство библиотек - просто биндинги и оболочки. Например pcntl_fork() и подобные функции пхп есть только на никсах.

 Нормальному проекту - нормальный хостинг     
А то натыкали на каждом шагу говнохостингов без необходимых модулей, с регистер глобалс, меджик куотес и прочей дрянью типа safe mode, а большинство людей по ним и судит   

 Серверная ось - ось, позиционируемая как серверная(вычеркиваем мак, венду для мобил), не имеющая серьезных недостатков в секьюрити-части(вычеркиваем венду) и предоставляющая набор софта для предоставления услуг.
Это ПРИМЕРНОЕ мое понимание серверности ОС =)


Ну в плане:
1) сервис/демон (например FTP-сервер)
2) в плане железа (типа "Вон в том шкафу наш сервер")
3) тип конфигурации системы от предназначения(сервер/воркстейшн/игровая конфигурация)

А для чего тогда было создавать такой системный вызов?

Просто в nix единица выполнения - процесс,
а в win  - поток, процесс - это просто группа потоков.

какая разница как это называть? суть одна   


Это скорее можно отнести к проблемам пхп, а не винды  
Претендуя на кросплатформенность, не стоит вводить ос-зависимые апи

з.ы. прекращаю оффтопить в этой теме   

Это сообщение отредактировал(а) VectorMan - 23.12.2006, 20:56

 В потоках одни и те же переменные, в процессах - разные.

 Ну я же так и написал:     

 Ну а разве место пхп не на серверах?    Зачем тут кроссплатформенность, достаточно поддержки только серверных ОС   

P.S. Хотя я видел извращенцев, которые гуи на пхп писали ;)
Правда php-gtk загнулся, хотя туда ему и дорога =) К первоисточникам     

Я говорил про потоки создаваемые вызовом rfork в freebsd, читай внимателнее   

Веление времени. Изначально никаких трэдов там не подразумевалось. (исправлено в связи с более подробным изучением сабжа)


Суть разная. Процесс - это не группа потоков. Это отдельная сущность. Архитектурная организация у них разная, способы взаимодействи и уровни изоляции.

Ну тогда о чём мы спорим, если ты для себя всё решил? Если ты думаешь что у Юникс нет security issues, то боюсь тебя ждут серьёзные разочарования. Вообщем как всегда виндовс == сакс == маздай, юникс == рулез == форэва   

 А разве я спорить начал?   
Я просто высказался насчет "серверности" венды   
Спорить я не собирался, но пришлось...

 Я так не думаю. На практике нереально написать что-либо большое без ошибок.
Однако практически сразу после появления ошибки в никсах, она фиксится. В отличии от критических уязвимостей в винде. Сколько там wmf-сплойт гулял до выхода заплатки?   
Сейчас ситуация такая же. Критическая уязвимость есть, а заплаток нету.

А что такое CLI и Rotor?

Процесс определяет набор сегментов кода/данных/стека. Поток ничего не определяет, а описывает текущий адрес в сегменте кода (контекст потока) и локальное хранилище, кстати редко используемое. Всё.

Наследование процессов реализовано в винде так же как и наследование любого другого объекта ядра (см. параметр bInheritHandles в CreateProcess).

Баг с "уязвимостью винды в результате стрёмного мессиджбокса" нашли китайские хакеры, вооружённые IDA .

Не собирается под современные версии винды - там #define WIN_VER четко рубит  Так что эта бага не может выскочить ненароком. Представляет опасность только при злонамеренном использовании. Скоро, наверное, пофиксят.