[locale] Re: [locale] Re: [locale] "Кpивые" руки()

[Vlad Harchev <hvv@hippo.ru>]

On Mon, 16 Jul 2001, Victor Wagner wrote:

> > >
> > > >  Всякие расчетные с большими об[емами данных. Представь обработку изображения
> > > > со спутника, размером несколько гигов, на многопроцессорной машине.
> > > > Максимальный размер shared memory очень мал - на линуксе по дефолту 32 мега
> > >
> > > Какой такой shared memory? SYSV? А mmap?
> >
> >  Да, System V shared memory.
> >  А mmap - менее приемлим. Особенно если хочется иметь какую-то портабельность
> > кода на win и unix или не надеятся на интеллектуальность ядра при работе с
> > памятью.
> 
> Где-то я уже писал, что единственное оправдание для тредов под Unix -
> общая codebase для Unix и Win.

 Ну нет- mmap неприемлем при работе с большими об[емами данных, которые
строятся на основе других данных (грубо говоря - когда нет файла, в котором
есть то что надо расшарить в памяти). Ядро будет с непредсказуемой логикой
пытаться запихнуть mmap'нутую память в какой-то файл (что приведет к
торможению в непрогнозируемые моменты времени и расходу места на диске). Еще
хуже, если надо расшарить какие-либо структуры данных типа списков, деревьев и
пр., использующих указатели. Семантика mmaped memory не гарантирует
возможность расположения начала данных по адресу, который хочет юзер (и
возможность зависит от кол-ва shared libs, ядра ОС и его версии и пр.) - а
следовательно указатели в каждом из процессов которые mmap'ят память могут
указывать на разные данные в памяти.
 
> Ибо Unix тем и приятен для программиста, что в нем можно надеяться
> на интеллектуальность/надежность/логичность/соответствие стандартам
> ядра, библиотек, стандартных утилит etc.

 Во многих коммерческих юниксах это не всегда справедливо (особенно логичность
и интелектуальность), но в целом согласен.

 Best regards,
  -Vlad