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

Имя:
e-mail:
FIDO:
Home page:
сохранить данные о вас

Тема:

> > в общем-то логично, раз память хоть кем-то продолжает использоваться ;) Было бы весмьма неприятно, когда процесс накрывался по причине обращения к несуществующему адресному пространству, убитом другим процессом. Или уже занятым следующим, это все вообще могло бы привести к непредсказуемым результатам.. Поэтому есть такой замечательный механизм, как семафоры ;) Кто мешает задействовать семафор и по сигналу высвобождать память во всех процессах? Причем, заметьте, все произойдет крайне корректно, как только все процессы найдут время отработать семафор и скажут DosFreeMem, память системой будет высвобождена и никто не пострадает.
> 
> Ох...
> Вы говорите это все здесь совершенно не в кассу. Обратится у меня второй процесс по инвалидному адресу если я из него отмаплю шареную память извне, или нет - это _мое дело_ ;) Семафоры тут вообще непричем. Проблема заключается в том, что примапливать память процессу можно извне (весь разговор начаслся с того, что это достоинство), а отмапливать назат можно только из самого этого процесса. Что в моем случае уничтожало все то самое достоинство, потомучто если мне убивать память все равно надо в получающем процессе, я ее и мапить оттудаже могу (DosGetSharedMem'ом)...
> 
> > >только тогда, кагда это необходимо и целесообразно. При выделении шареной памяти тратится не столько физическая (вернее виртуальная, которой еще больше) память, сколько адресное пространство шареной памяти, понимаете ;) А оно одно _на все процессы_.
> > 
> > Насколько я понимаю, адресное пространство (диапазон адресов памяти) выделяется только когда, когда его (диапазон, т.е. какой-то объем памяти) запросят. Если вы не запрашиваете память (не используете в вашей задаче), то и адресное пространство _вашей_ задаче не выделяется. Оно _доступно_ но _не_выделяется_. Это же фактически куча. Вы же говорите о том, что любой задачи заранее выделяется некий чанк шареной памяти, что сомнительно, т.к. незачем.
> 
> Господи, чего-чего я говорю? Ж))))) Даже уж незнаю просить ли вас перечитать заново, или...
> Ну ладно, обьясняю на пальцах.
> Вот выделил какойто процесс шареную память скажем размером с половину всего шареного региона. Отдал ее какому-то своему соседу. и вот они ее юзают. Теперь если какой-то совершенно посторонний процесс выделяет шареную память - она выделится только среди тех адресов, которые не совпадают с виртуальными адресами соответственно выделенной в первом процессе. Проблема _не в том_, что кончается память, памяти может оставаться сколько угодно, но адресов для назначения в виртуальном адресном пространстве процесса может не остаться. Понимаете? ;) Поскольку виртуальные адреса обьектов шареной памяти _одинаковы во всех процессах_
> 
> > Логично, раз это - механизм, общий для всех :) К примеру, очереди сообщений тоже общие и их тоже можно забить, и что, теперь ими не пользоваться? ;))
> 
> Лимит на них как правило бывает таков, что он, вероятно в число состоящее из нескольких знаков раз превосходит то, что может быть достигнуто на практике. С шареной памятью это не так. К примеру, потенциально обычной памяти доступно ~512-64мб на _каждый_ процесс, а шареной ~512-64мб _на все_ процессы, причем сумма шареной и самой большой используемой приватной (среди всех процессов) не превышает 512мб. (цифры грубые и естесственно, не включают high mem)
> Ну и наконец - где это я говорил что шареной памятью не надо пользоваться? :Е Я говорил что пользоваться ей надо в наших условиях осторожно и _разумно_. Еще я говорил, что хорошо было бы _не тратить_ пространство шареного региона тогда, когда это и не нужно...
> 
> > Просто надо аккуратно действовать, вот и все.. Кстати, раз уж вам удавалось забивать всю sharedmem, интересно было бы узнать какого она объема в итоге оказалась (на будущее ;)))
> 
> Минимальная предельная граница для шареной памяти может составлять 64мб. Это если какой-то процесс сожрет много приватной и граница между регионами сдвинется в угоду этого... Сколько было реально когда возникали проблемы - хз. Все программы начинали падать и ругаться что немогут создать шареную память...
> 
> > > 4. То что это реально достижимо я тоже отметил неспроста. Занять например всю виртуальную память реальными задачами довольно сложно. На практике я например такого не встречал
> > 
> > Это, видно, памяти и места на hdd у вас всегда много было :)) И вы, скажем, здоровенные матрицы  не считали ;)
> 
> Ну о _собственных_ программах тут речь вообще не шла... Ж) В них конечно никаких подобных проблем не было бы Ж) Шареную память очень массивно используем пм. Все длли грузятся в нее. Ну и еще - выделяется она у нас с гранулярностью в 64к. даже если ктото 2 раза выделит по одной странице - выделится 128к...
> 
> > Увы - не отпадают. Во-первых, софт далеко не всегда в исходниках (дрова, та же ява, коммерческий софт и т.п.), к ним пишут врапперы (попробуйте, поставьте яву на bsd - увидите), приходится прыгать с бубном и в итоге зачастую все равно ничего тольком не работает. Во вторых, помимо исходников нужно еще, чтобы автор исходников предусмотрел возможность их сборки под ту же bsd, иначе не заработает. Точно так же, как не заработает, если попытаться собрать под ось (gcc-то имеется). Кроме того, что работает на i386 не факт, что заработает на amd64, даже если вроде корректно соберется.. А так, вообще, на том же хоббесе и под ось много чего лежит в исходниках ;))
> 
> Лежит лежит Ж) только вот собрать в emx то, что прекрасно слету соберется в бсд и линуксах гораздо сложнее... Несоизмеримо просто, я бы сказал. Несмотря ни на какие единичные исключения случаев граблей, присудствующих с этим и в бсд ;)
> 
> > Это был просто пример из жизни, который произошел совсем недавно, не более того. Спотык ровном месте. Сервак должен был быть непременно на *никс, и кто же знал, что железо не подойдет? Хотя железо типа 3com и хоть и гигабитное, но не такое уж и хоть и  совсем современное.. А sundance -тому вообще уж полно лет, но оно в ядре опена помечено как *borked* до сих пор... Впрочем, это я так уже, на жизнь жалуюсь ;) 
> > Пример был приведен просто для того, чтобы показать, что там тоже не так уж все радостно и солнечно, и что в оси бывает иногда что-то, чем не может похвастаться система, профилирующая в какой то задаче (немного коряво выразился, но смысл, думаю, понятен ;)
> 
> Понятен ;) Но почему это для бзд уже тот факт что она не _абсолютно идеальна_, является основанием для того чтобы ставить ее вровень (?) с ос2, на которой проблем гораздо больше Ж) И естесственно в каких-то конкретных точках наличие проблемы не совпадает в пользу бсд Ж) Есть случаи когда в бсд проблема а в ос2 нет. Однако в _общем_ в ос2 проблем гораздо больше, и соответственно вероятность их возникновения на реальном сервере гораздо выше, вот и все ;) Надеюсь, это тоже понятно Ж)
> 
> > Вовсе нет, точно так же актуальны, просто микрософт заменяет часто совими поделками поделки юникс-сообщества. Навязывает. К примеру, тот же стек в винде микрософтовский, и хотя он хуже bsd'шного, деваться им некуда, потому как - встроен. То же касается вообще всех сетевизмов (профиля BSD). Или вот, к примеру, MS Exchange... - неужели им полбзуются от хорошей жизни или большого ума? ;))
> > А ось просто под шумок старается собирать все лучшее и оттуда и отсюда, вот и все ;))
> А вы действительно уверены что стек в последних виндах хуже чем в бсд? ;) Я вот нет... :-\ Ну а уж про наш осевой стек, хоть он и гдето когдато бсдшный в своей природе тут уж точно говорить нечего... Ж)
>

_, __, _, __, /_\ \|_) /_\ \|_) \| \| \| \| \| \| \ ~ ~ ~ ~ ~ ~ ~