RU/2: Форум. Общение пользователей и разработчиков OS/2 (eCS). : Вставлю и свои 5 копеек =))


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : ???
To : Tsirtaichysp
Subj : Вставлю и свои 5 копеек =))

> Вы не поняли ;) DosFreeMem нужно делать _во всех_ процессах получивших доступ к шареному обьекту... Поэтому из процесса A я могу смапить шареную память в процесс B при помощи DosGiveSharedMem, а вот высвободить ее после этого только из процесса A невозможно. Речь шла об этом. ;)

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

>только тогда, кагда это необходимо и целесообразно. При выделении шареной памяти тратится не столько физическая (вернее виртуальная, которой еще больше) память, сколько адресное пространство шареной памяти, понимаете ;) А оно одно _на все процессы_.

Насколько я понимаю, адресное пространство (диапазон адресов памяти) выделяется только когда, когда его (диапазон, т.е. какой-то объем памяти) запросят. Если вы не запрашиваете память (не используете в вашей задаче), то и адресное пространство _вашей_ задаче не выделяется. Оно _доступно_ но _не_выделяется_. Это же фактически куча. Вы же говорите о том, что любой задачи заранее выделяется некий чанк шареной памяти, что сомнительно, т.к. незачем.

> так произошло, в конце концов в этом вина разработчика приложения. В случае же с окончанием шареной памяти (заполнением шареного адресного пространства) ресурс становится недоступен _для всех процессов системы_.

Логично, раз это - механизм, общий для всех :) К примеру, очереди сообщений тоже общие и их тоже можно забить, и что, теперь ими не пользоваться? ;))
Просто надо аккуратно действовать, вот и все.. Кстати, раз уж вам удавалось забивать всю sharedmem, интересно было бы узнать какого она объема в итоге оказалась (на будущее ;)))

> 4. То что это реально достижимо я тоже отметил неспроста. Занять например всю виртуальную память реальными задачами довольно сложно. На практике я например такого не встречал

Это, видно, памяти и места на hdd у вас всегда много было :)) И вы, скажем, здоровенные матрицы не считали ;)


> В общем, лично я со многим совершенно согласен Ж) Правда я не взял бы на себя ответственность утверждать, что там-то или там-то нельзя "жить" _вообьще_ ;) Для меня лично - это безусловно так, а за всех я бы говорить не стал... ;) Кто-то же живет по-видимому ;) А кто-то с другой стороны ни при каких условиях не смог бы чуствовать себя комфортно в ос2...

Безусловно, на вкус и цвет, как известно... Но вот я попробовал и делюсь своими впечатлениями ;)

>есть, но у меня не поставлено... Кстати, нативный флеш у нас не последний,

Да, 7-й уже через враппер, но есть.

> а жаву вроде не дают забесплатно...

Нативную - да, за денюжки (или по секрету ;), а через враппер - халявная, на иннотеке лежит.

> Так вот - начало хорошее, а потом что-то опять какие-то странные посылки Ж) По поводу других версий юникс - обычно софт существует в исходниках, и тут другие версии я так понимаю отпадают
;)

Увы - не отпадают. Во-первых, софт далеко не всегда в исходниках (дрова, та же ява, коммерческий софт и т.п.), к ним пишут врапперы (попробуйте, поставьте яву на bsd - увидите), приходится прыгать с бубном и в итоге зачастую все равно ничего тольком не работает. Во вторых, помимо исходников нужно еще, чтобы автор исходников предусмотрел возможность их сборки под ту же bsd, иначе не заработает. Точно так же, как не заработает, если попытаться собрать под ось (gcc-то имеется). Кроме того, что работает на i386 не факт, что заработает на amd64, даже если вроде корректно соберется.. А так, вообще, на том же хоббесе и под ось много чего лежит в исходниках ;))


> Ну а насчет проблем с карточками и последовавшего вывода... это уж извините вообще ;) Не ожидал Ж) Ответте сами себе - в ос2 неподдерживаемых/проблемных сетевух существует _меньше_ чем в BSD? ;) Так чтоли? ;) Или вот скажем, если есть проблемы с сетевухой A в ос2 и BSD как вы полагаете вероятность того что они будут пофикшены там и там? И если вы нашли конкретный пример не работающей во фре и работающей в ос2 сетевухи, это конечно замечательно, но это, опять таки, правило или исключение? ;)

Это был просто пример из жизни, который произошел совсем недавно, не более того. Спотык ровном месте. Сервак должен был быть непременно на *никс, и кто же знал, что железо не подойдет? Хотя железо типа 3com и хоть и гигабитное, но не такое уж и хоть и совсем современное.. А sundance -тому вообще уж полно лет, но оно в ядре опена помечено как *borked* до сих пор... Впрочем, это я так уже, на жизнь жалуюсь ;)
Пример был приведен просто для того, чтобы показать, что там тоже не так уж все радостно и солнечно, и что в оси бывает иногда что-то, чем не может похвастаться система, профилирующая в какой то задаче (немного коряво выразился, но смысл, думаю, понятен ;)

> Ну как тут сказать, с одной стороны это так - действительно посередине. Но вот если подумать - то защет чего? Защет того что в ос2 активно эксплуатируются юникс технологии? ;) Так ведь видите, в винде то все, скажем, порты из юникса существуют не хуже чем в ос2 ;) Только вот видимо там они не так актуальны как в ос2, правда? ;)

Вовсе нет, точно так же актуальны, просто микрософт заменяет часто совими поделками поделки юникс-сообщества. Навязывает. К примеру, тот же стек в винде микрософтовский, и хотя он хуже bsd'шного, деваться им некуда, потому как - встроен. То же касается вообще всех сетевизмов (профиля BSD). Или вот, к примеру, MS Exchange... - неужели им полбзуются от хорошей жизни или большого ума? ;))
А ось просто под шумок старается собирать все лучшее и оттуда и отсюда, вот и все ;))

Thu 20 Oct 2005 20:12 Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7) Gecko/2004061



Programmed by Dmitri Maximovich, Dmitry I. Platonoff, Eugen Kuleshov.
25.09.99 (c) 1999, RU/2. All rights reserved.
Rewritten by Dmitry Ban. All rights ignored.