Есть ли будущее у DELPHI?

Не телефонный разговор, отвечу как-нибудь с компа

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

А мне вот больше интересно, как им все-таки удалось сертифицироваться без того же fork'а? И чего после этого такая сертификация стоит?
А то тем же разработчикам cygwin'а не пришлось бы для реализации fork извращаться...

Цитата Qraizer @ 02.03.12, 17:50

А что делать с захваченными на данный момент именованными Mutex-ами, например? Как дублировать нитки процесса, если к ним привязаны окна? Как помирить именованные pipe-ы, которые связаны с удалёнными серверами и по некоторым из которых некоторые из ниток общаются вот прям счас? Как это всё fork() решает у вас?

Для начала хочу заметить, что идеологически *nix системы не рассчитаны на людей, которые не ведают, что творят
На счет многопоточности. Мне не попадались ситуации, когда хотелось сделать fork без какого-то из excec'ов в условии нескольких уже работающих потоков.
Обычно потоки создаются после fork'а в дочернем процессе. В этом случае никаких проблем нет. Нитки fork'ом не дублируются и вообще при fork'е в условиях уже запущенных потоков возникает ряд проблем(даже при использовании pthread_atfork), так что лучше так просто не делать(оно, собственно, и не требуется).
На счет именованных pipe'ов. В windows они чересчур усложнены(что не понятно при наличии сокетов). В никсах все проще.
Но в любом случае все в порядке, ибо все открытые дескрипторы ресурсов дублируются(см. dup()) при fork'е, но как правило, родительский процесс закрывает такого рода каналы, отдавая их для работы дочерним. Кстати, для обмена между родительскими и дочерними процессами нет необходимости создавать именованный канал - достаточно неименованного(т.к. дескрипторы будут продублированы), что довльно таки удобно.
Но да, fork может привести к проблемам в условиях многопоточности, хотя <см. первое предложение>

Добавлено 02.03.12, 19:49
Блин, мы ж тут оффтопим по страшному...

Угу, оффтопим. Наверно, тема топика себя большей частью исчерпала.
В целом понятно, fork() и у вас не беспроблемный, так что пользовать нужно с умом. Мне просто было интересно, захоти это сделать MS, чтоб ей пришлось для этого сотворить. Боюсь, овчина выделки реально не стоит, слишком велика разница в архитектурах ядер.

Цитата D_KEY @ 02.03.12, 19:38

Для начала хочу заметить, что идеологически *nix системы не рассчитаны на людей, которые не ведают, что творят

Это справедливо для любой системы. И дело тут не в мозгах, а в уровне реализуемой твоим кодом абстрации. Ты, к примеру, можешь и не знать, что работаешь под чьим-то мьютексом, который на пару иерархических уровней выше. А в другом приложении этот же твой код является вершиной архитектурной иерархии. Как быть? Как писать библиотеки? Остаётся одно: на всякий случай не юзать никогда. Собственно, вот.

Цитата Qraizer @ 02.03.12, 20:48

Наверно, тема топика себя большей частью исчерпала.

Никто Delphi не защищает

Цитата Qraizer @ 02.03.12, 20:48

Ты, к примеру, можешь и не знать, что работаешь под чьим-то мьютексом, который на пару иерархических уровней выше.

В этом случае тебе не нужен fork без exec*

Цитата

Как писать библиотеки?

fork без exec в библиотеке? Разве что просто обертка над fork

Цитата

Остаётся одно: на всякий случай не юзать никогда. Собственно, вот.

Вывод неправильный
Для высоконагруженных демонов достаточно удобная штука. Посмотри на архитектуру nginx, appache и пр.

Кстати, вполне можно воспользоваться fork'ом вместо создания ниток, если не требуются большие объемы общих данных. Код в этом случае проще, а вероятность ошибок меньше.
Другое дело, что из-за кроссплатформенности использование fork ограничено, к сожалению. Вот если бы windows действительно была бы posix-совместимой... Эх.
Кстати, каким-нибудь android'ам, говорят, крышу сносит, если приложение делает fork

Сообщение отредактировано: D_KEY - 02.03.12, 22:53

Та понимаю я всё прекрасно, D_KEY. Я больше про винду рассуждаю. Но вот что касается первых двух ответов - это я говорил всё-таки обобщённо. Я считал, что fork() - с точки зрения дизайна софта это для POSIX нечто вроде CreateThread() для WinAPI. А выходит, что нифига. Это действительно больше аналог CreateProcess(), иначе зачем потом exec()-ать. Только менее накладный, возможно, но... ИМХО опять же овчинка выделку подводит стоимостью.

Цитата Qraizer @ 03.03.12, 04:03

Я считал, что fork() - с точки зрения дизайна софта это для POSIX нечто вроде CreateThread() для WinAPI.

Для POSIX это pthread_create
На самом деле ты просто не до конца понял идеологию. Процесс - это не что-то тяжелое и это не обязательно должно быть связано с самостоятельным исполняемым файлом и пр. и пр. А ОС может быть не просто внешней средой, но и помошницей Если нитки - это в первую очередь средство для оптимизации, то процессы - это в первую очередь средства архитектурной декомпозиции. Как-то так.
Жаль, что в windows так писать не получится.

Добавлено 03.03.12, 10:23

Цитата Qraizer @ 03.03.12, 04:03

Это действительно больше аналог CreateProcess(), иначе зачем потом exec()-ать.

Так не всегда нужно делать.
Как раз после fork'а в дочернем процессе ты сможешь вызывать что угодно, зная, что родителю ты уже никак не повредишь. Раз уж сравниваем с нитками. С другой стороны, даже если ты вдруг упадешь, до родитель об этом узнает и даже сможет тебя перезапустить.
Почему MS пошла своим путем и сделала лишь одну жесткую функцию для меня загадка...

Цитата [S]mike @ 02.03.12, 21:13

Никто Delphi не защищает

Дык некогда - работы много - в Delphi

Цитата D_KEY @ 03.03.12, 10:13

Если нитки - это в первую очередь средство для оптимизации, то процессы - это в первую очередь средства архитектурной декомпозиции.

Насчёт декомпозиции - у нас это тоже не редкость. А вот на предмет ниток - тут не соглашусь: у нас это всего лишь средство, позволяющее исполнять код процесса в нескольких местах. Необязательно одновременно, на это может не хватить ядер/процессоров, но с учётом вытесняющего планирования это неважно. У вас планируются процессы, у нас - нитки. У вас процесс по сути то же, что нитки для нас, а у нас процесс - это просто контейнер, ограничитель области видимости всего локального для приложения - объектов ОС, памяти, окон итп. Для нас fork() идеологически должен был был скорее клонировать нитки, но в таком качесвте он бесполезен.

Цитата Qraizer @ 03.03.12, 12:08

у нас это всего лишь средство, позволяющее исполнять код процесса в нескольких местах.

У нас тоже есть нитки, не забывай.
А вот взгляд на процессы, у Вас, более ограниченный. Т.е. то, что делаете вы, можно сделать так же у нас, а вот обратное не верно

Да, нитки у вас появлись. А у нас фиберы
Не ограниченный, а более логичный. Не всегда жирность интерфейса является плюсом.

Добавлено 03.03.12, 15:12
Как насчёт перетащить оффтоп на пару тем ниже?

Цитата Qraizer @ 03.03.12, 15:11

Не ограниченный, а более логичный. Не всегда жирность интерфейса является плюсом.

Большей логичности не наблюдаю. А в целом winAPI гораздо жирнее(причем не оправдано)...
У вас нет простой и четкой возможности пораждения дочерних процессов с целью распараллеливания без общего адресного пространства. И это все-таки минус А с fork работать как правило даже легче, чем с нитками.
В Linux вообще есть clone, который через набор флагов управляет тем, как и что разделяют родительский и дочерний процесс, что в общем-то стирает грань между процессами и нитями. По крайней мере какое-то время назад(может и сейчас так же) и pthread_create и fork конкретно в linux работали через clone.

Добавлено 03.03.12, 19:46
Оффтоп переноси, конечно

Цитата D_KEY @ 03.03.12, 10:13

нитки - это в первую очередь средство для оптимизации

Не согласен я. При чем тут оптимизация, если во многих случаях нитки юзают одно и то же ядро(процессора)? Думаю они также просто являются одним из средств организации архитектуры приложения.

Добавлено 04.03.12, 11:13

Цитата Keepun @ 02.03.12, 15:02

А для тебя нет разделения на рынки? Общий с одними правилами?

на Десктопе - Винда (потому что нужно работать)
на Сервах - никсы (плевать на периферию, которой нет, но дайте выжать максимум)
на Мобильниках - конкуренция даже на уровне оборудования.

Рынки разные совершенно.
На мобильниках ОСи кардинально отличаются от десктопный и серверных.

Для меня как раз есть, Qraizer же обошелся общим словом "рынок", я и уточнил.

Добавлено 04.03.12, 11:21

Цитата Qraizer @ 02.03.12, 16:41

Цитата korvin @ 02.03.12, 14:34

Вообще-то, я лишь упомянул, что в Plan 9 (которая, кстати, даже не является POSIX-совместимой) полносистемная поддержка юникода появилась раньше, чем в виндах.

Ты сказал не это.

Я сказал именно это.

Цитата Qraizer @ 02.03.12, 16:41

И к тому же это не правда. Полноценная поддержка юникода не могла появиться раньше появления самого юникода в 91 году. В это время NT разрабатывалась уже 3 года.

Ну дык Plan 9 разрабатывается с середины 80-х. http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs#Unicode

Цитата Qraizer @ 02.03.12, 16:41

Первый релиз вышел в 93-м и полностью поддерживал юникод. Об NT вообще имеет смысл говорить, что она поддерживает ASCII с кодовыми страницами, ибо сама внутри построена целиком на юникоде.

Это не помешало туче приложений под винду не поддерживать Юникод вообще