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

[Повстанець]

Цитата korvin @ 04.03.12, 15:52

Что значит "с произвольным"? Что будет в случае одновременной записи в один и тот же участок?

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

Цитата korvin @ 04.03.12, 15:52

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

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

[D_KEY]

korvin, ты все валишь в одну кучу, я прям даже не знаю, что ответить.

[Бобёр]

Цитата

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

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

[Qraizer]

Цитата korvin @ 04.03.12, 11:12

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

Ага, теперь оказалось, что дело в приложениях, а не ОСях. Ну да, тролингмод, что уж там.
D_KEY, если код приложения исполняется одновременно в нескольких точках, каждая из которых принадлежит отдельному адресному пространству, это нельзя называть одновременным исполнением в разных точках, это можно назвать одновременным исполнением нескольких копий приложения. Это было возможно и в Win16.

[D_KEY]

Цитата Qraizer @ 04.03.12, 21:34

D_KEY, если код приложения исполняется одновременно в нескольких точках, каждая из которых принадлежит отдельному адресному пространству, это нельзя называть одновременным исполнением в разных точках

Ты можешь называть как угодно. Но у нас больше вариантов для построения архитектуры параллельной обработки.
И если бы ты не смешивал понятие исполняемого файла и процесса, ты бы лучше меня понял.

[Qraizer]

Ну и что, что больше? fork() + exec() == CreateProcess(), в остальных случаях fork(), как я понял, либо ограничен, либо требует аккуратности. И зачем тогда? Для галочки? Я по Стандарту могу вывести строку на консоль шестью разными способами, но пользуюсь преимущественно двумя, одним из C, другим из C++. Остальные для экзотики, нужны раз в пятилетку, т.е. два раза за время актуальности текущего Стандарта.
И я и не смешиваю. Я говорю о приложении, а не исполняемом файле. Можно вчетвером сесть в одно такси, а можно заказать каждому персональное, но одинаковое. До цели доедем одинаково быстро, только платить больше, общаться в поездке затруднительно, и пространство дороги расходуем расточительно. Зато да, каждый может сморкаться, не боясь, что затронет эстетические чувства соседа. Водитель не в счёт, он обслуга - мы приедем, он за нами салон почистит. Правда, может и с матами выкинуть посреди дороги, и оставшиеся трое в пункте назначения будут удивлены отсутствием четвёртого. Ну он же сам виноват, а так выкинуты могли бы быть все четверо. Зато в нашей таксисткой компании нас трое доехало б с большей вероятностью, чем все четверо нет.
Нитка - это ещё одна точка исполнения в процессе. Не более чем. Для чего это можно использовать - вопрос другой. Оптимизация тут не главное. И безопасность тоже - для чего может потребоваться рассаживаться по разным машинам... скажем так, с исполнением в песочнице это слабо соотносится. Word не создаёт новую нитку на каждый документ. И процесс не создаёт. Но пользователю по барабану, он видит разные окна.

[D_KEY]

Цитата Qraizer @ 05.03.12, 20:30

в остальных случаях fork(), как я понял, либо ограничен, либо требует аккуратности. И зачем тогда? Для галочки?

Для работы
Если не нужно общее адресное пространство(или оно вредит), нужна изолированность, нужен перезапуск дочерних, нужен запуск от другого пользователя и т.д. и т.п. - будем использовать процессы.
Нитки используем тогда, когда нужно общее адресное пространство. Ну и когда хочется fork, но нужен переносимый код.
Жаль, что не все ОС(точнее их создатели) любят стандарты

Хочешь узнать о применении процессов/потоков и их правильном сочетании, полистай какую-нибудь классику, например, на тему сетевого программирования.

[Qraizer]

Та чё листать-то. Мы ж об одном говорим. Проскакивали аргументы "оптимизация" и "надёжность", но дело-то не в них. Я ж не против процессов, я аргументирую отсутствие fork()-а в виндах и утверждаю, что несколько точек исполнения в одном процессе не есть то же самое, что несколько процессов с одной точкой исполнения в каждом.

[amk]

Qraizer, не очень понял к чему относится твой пример с такси.

fork(), по мне, это когда все пассажиры едут в одном такси. Форкнутые процессы обычно разделяют исполняемую часть (такси). Что обеспечивает высокую эффективность вилки - она почти ничего не делает - только дублирует изменяемые данные (которых к этому моменту обычно не много) и разные дескрипторы. Поэтому в POSIX-системах использование отдельных процессов часто почти не уступает по производительности использованию потоков.

[D_KEY]

Цитата Qraizer @ 05.03.12, 23:35

я аргументирую отсутствие fork()-а в виндах

Чем? Я не понял.
И, главное, зачем мотивировать? Если утверждается, что POSIX.1, значит fork быть обязан...

Цитата

и утверждаю, что несколько точек исполнения в одном процессе не есть то же самое, что несколько процессов с одной точкой исполнения в каждом.

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

[Qraizer]

amk, детали реализации несущественны. Даётся ли это дёшево или дорого - это опять же вопрос оптимизации, каковой в теме наличия fork() отношение имеет, но второстепенное.
Сдампить процесс в DOS легче лёгкого. У него всех связей с ОС - это текущий PSP. Подмениваем - и резидент вдруг стал задачей переднего плана, а текущий ушёл в бэкграунд. Его можно даже в хибернет увести. Я сам писал тулзу, по горячей кнопке выгружающую текущий процесс и запускающую в освободившейся памяти новый. Тестил BC++ 3.1, во время компиляции которым жал и тем самым запускал DOOM 2, по выходу BC продолжался, как ни в чём не бывало. Была такая тулза, PlayerTools, много что умеющая. В частности и QuickSave/QuickLoad для игрушек, такими возможностями не обладающие. В Win16 сдампить задачу ненамного сложнее, притом что все они выполняются в совмещённом адресном пространстве. Просто в то время приложения были всё ещё слабы возможностями и с ОС связаны малым объёмом сервиса. Если ваши процессы имеют от ОС так же мало сервисов, fork()нуть его, подозреваю, несложно.
Процессы Win32 получают от ОС очень много сервисов, причём ОС их не столько поставляет, сколько выступает в роли диспетчера между процессами-клиентами и процессами-серверами. И таких связей набегает приличный граф.

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

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

D_KEY ответил.

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

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

Это относительно решаемые вопросы, потому и "по мелочи".

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

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

[OpenGL]

Цитата Qraizer @ 05.03.12, 20:30

Я по Стандарту могу вывести строку на консоль шестью разными способами,

cout/printf ... а какие еще?

[Бобёр]

fprintf с дескриптором 1 или 2...

[trainer]

fwrite, puts/fputs

[Бобёр]

WriteConsoleOutput/WriteConsoleInput