s/узазанному/указанному/

s/узазанному/указанному/

Интересуют Linux, Windows, *BSD, OS X.

Точнее, слухи "у shmat может не получиться приаттачить память по указанному адресу".

Думаю, ноги растут от mmap. По крайней мере в linux shmat отображает память в адресное пространство процесса через do_mmap. Слухи, что "у mmap может не получиться приаттачить память по указанному адресу" можно подтвердить в man mmap.

mm

Про mmap в мане четко написано, что адрес -- это хинт. А про shmat -- If shmaddr is NULL, the system chooses a suitable (unused) address at which to attach the segment.

If shmaddr isn't NULL and SHM_RND is specified in shmflg, the attach occurs at the address equal to shmaddr rounded down to the nearest multiple of SHMLBA. Otherwise shmaddr must be a page-aligned address at which the attach occurs.

( http://linux.die.net/man/2/shmat )

И типо даже Conforming to SVr4, POSIX.1-2001.

В общем, действительно shmat может отказаться замаппить куда надо или это слухи?

ЕЩЕ РАЗ: shmat использует do_mmap. Если ты указываешь адрес в shmat, куда отобразить память - то считай, что для этой цели вызывается mmap с твоим этим адресом и флагами MAP_SHARED и MAP_FIXED. Даже с MAP_FIXED, mmap может обломиться (man mmap), а раз обломится mmap, то и shmat тоже.

ps: это все по linux, думаю в *BSD и др. все аналогично.

другими словами -- linux is badly broken

У меня гораздо худшие выражения крутятся на языке :-)

> У меня гораздо худшие выражения крутятся на языке :-)

это не только в линуксе. В соляре есть похожая проблема. ссылки нет, но вот тут упоминают: http://www.youtube.com/watch?v=6chLw2aodYQ см примерно 42:30 - 43:30, back-aliasing.

А что делать этой функции если память по этому адресу уже занята?

или надо выделять пару гиг адресного пространства во всех процессах специально для проецируемой памяти?

Это не слухи, так есть и это правильно.

> Это не слухи, так есть и это правильно.

Вот и мазозисты подтянулись :-)

> надо выделять пару гиг адресного пространства во всех процессах специально для проецируемой памяти?

Если тебе 2 оставшихся гигов не хватит, иди в 64 бита.

А еще я подозреваю, что там вообще не надо выделять ничего, надо только правильную таблицу дескрипторов страниц установить.

* мазохисты

1 оставшегося 1го гига, потому что еще 1 занят ядром

2 если одна программа выделит 2 гига шареной памяти - остальные обломаются, т.к. адреса памяти должны быть уникальными в пределах системы.

3 сам мазозист, иди читай книжки до просветления.

> 1 оставшегося 1го гига, потому что еще 1 занят ядром

2 гига *вместе* с тем гигом, который занят ядром. Тупая идея выделить 1+2 гига мне и в голову не пришла.

> 2 если одна программа выделит 2 гига шареной памяти - остальные обломаются, т.к. адреса памяти должны быть уникальными в пределах системы.

Уникальными, так как криворукие программеры по другому не осилили?

> 3 сам мазозист, иди читай книжки до просветления.

Глупо.

> иди читай книжки до просветления.

Книжки тут вряд ли помогут. Другое дело, что возможно существует workaround?

Как минимум: несколько процессов должны читать один блок памяти, и при этом он должен видеться всеми процессами по одному и тому же адресу.

Может можно попробовать перебором (инкрементируя на ...) найти такой адрес?

>> > 2 если одна программа выделит 2 гига шареной памяти - остальные обломаются, т.к. адреса памяти должны быть уникальными в пределах системы.

>> Уникальными, так как криворукие программеры по другому не осилили?

какие криворукие программеры? Где ты видел описанную реализацию?

...

процесс 1 выделил и замапил себе память по адресу 12345

в процессе 2 адрес 12345 уже занят, но он тоже хочет ее себе замапить, что тут "перебирать (инкрементируя на ...)"?

Юникс системы и даже виндовс(!) проектировали ни хрена не идиоты.

Понавылазили недоученные студенты - то им иксы кривые, то mmap не так работает.

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

> в процессе 2 адрес 12345 уже занят, но он тоже хочет ее себе замапить

Кем или чем занят???

(а если бы shmat действительно так должна была бы работать как ты рассказываешь, то в позиксе об этом написали -- да, есть такое ограничение).

1. Ты вообще в курсе, что адреса внутри процесса вообще не имеют ничего общего с физическим адресом?

2. Мне надо именно *одну и ту же физическую* память расшарить по разным процессам. Почему я не могу сделать это так, чтобы логические адреса внутри процесса были одинаковые?

* чтобы логические адреса внутри обоих процессов были одинаковые?

>> Кем или чем занят???

чем угодно, malloc, сегмент кода, стек и т.д.

ты наверное не понял

то что я рассказывал - это не то как работает shmat. Это то как ему пришлось бы работать, если бы нужно было возвращать одинаковые указатели во все процессы.

А чем вообще мешают разные адреса в разных процессах?

Ну подумаешь, будешь вместо указателей хранить смещения. За 12 лет мне это еще ни разу особо не помешало...

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

> чем угодно, malloc, сегмент кода, стек и т.д.

Ядру безразлично что там. Лишь бы не структуры ядра. Даже если там что-то исполняется и по переключению таблицы дескрипторов страниц там окажется неисполнимая страница -- будет sigsegv и программер ССЗБ. А ядру пофиг.

> Ну подумаешь, будешь вместо указателей хранить смещения. За 12 лет мне это еще ни разу особо не помешало...

Вот-вот, и думаешь я по твоему примеру тоже буду мазо^W соглашусь с тормозными смещениями?

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

Ядро вообще мало что резервирет в процессе, и malloc -- это _не_ функция ядра, а функция libc.

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

Ты в курсе, что в одном процессе в байте по адресу 0хBLA-BLA-BLA может быть записано число 1, а в другом процессе по тому же адресу 0хBLA-BLA-BLA записано число 9?

Так что ничего резервировать не надо.

Да в курсе

только при чем тут это?

тебе нужно иметь память замапленную во все процессы по 1му адресу

значит нужно чтобы по этому адресу ничего не было во всех процессах.

> другими словами -- linux is badly broken

во фряхе man mmap говорит абсолютно то же самое что адресс это только хинт.

>> Вот-вот, и думаешь я по твоему примеру тоже буду мазо^W соглашусь с тормозными смещениями?

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

Ну или быть может надеяться на то, что оно будет мапиться по 1му адресу...

>> > другими словами -- linux is badly broken

>> во фряхе man mmap говорит абсолютно то же самое что адресс это только хинт.

И в винде тоже, да и наверное везде. Потому что похоже это единственно возможный разумный алгоритм работы с проецируемой памятью.

> тебе нужно иметь память замапленную во все процессы по 1му адресу

да.

> значит нужно чтобы по этому адресу ничего не было во всех процессах.

нет.

2-е с первым не связано.

>> во фряхе man mmap говорит абсолютно то же самое что адресс это только хинт.

Мне shmat нужен, а не ммап.

>> И в винде тоже

Ссылку? Или это твои домыслы?

Кстати: http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/shmat...

shmat workaround

Вполне бы устроило, например, чтобы в разных процессах вызов shmat без хинта и с одинаковыми параметрами давал всегда один и тот же адрес хотя бы при условии что *в каждом из этих процессов этот вызов -- первый".

> Вполне бы устроило, например, чтобы в разных процессах вызов shmat без хинта и с одинаковыми параметрами давал всегда один и тот же адрес хотя бы при условии что *в каждом из этих процессов этот вызов -- первый".

если есть такой контроль за процессами, не значит ли это, что они все форкаются из одного родителя? если да, это меняет дело...

>> >> во фряхе man mmap говорит абсолютно то же самое что адресс это только хинт.

>> Мне shmat нужен, а не ммап.

Сдается мне, ты идиот. Тебе уже раз 5 сказали, что shmat работает через mmap и то что в man shmat не написано явно, что адрес не более чем хинт - всего лишь погрешность документации.

>> >> И в винде тоже

>> Ссылку? Или это твои домыслы?

В MapViewOfFile желаемый адрес не указывается вообще,

MapViewOfFileEx параметр lpBaseAddress

http://msdn.microsoft.com/en-us/library/aa366763(VS.85).aspx

четко написано, что винда на него кладет.

>> если есть такой контроль за процессами, не значит ли это, что они все форкаются из одного родителя? если да, это меняет дело...

главное после форка память не выделять и exec не дергать :)

тогда наверное получится все замапить по 1му адресу если повезет.

скорее всего так и будет, но закладываться на такое поведение не стоит.

вообще, исходники ядра тебе зачем дают?) открой

mm/mmap.c:arch_get_unmapped_area() - там все написано

> Сдается мне, ты идиот. Тебе уже раз 5 сказали, что shmat работает через mmap

Речь шла про BSD, про которую никто не говорил "shmat работает через mmap"

> главное после форка память не выделять и exec не дергать

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

в бсд оно примерно также сделано

(на самом деле в линуксе есть do_mmap через которую работают sys_mmap и sys_shmat)

> вообще, исходники ядра тебе зачем дают?) открой mm/mmap.c: arch_get_unmapped_area() - там все написано

Исходники вещь полезная, но я так полагал, что технология "юзаем настоящие адреса, а не смещения в расшаренной памяти" должна быть достаточно популярна и народ знает, что для этого надо делать.

> вообще, исходники ядра тебе зачем дают?) открой mm/mmap.c: arch_get_unmapped_area() - там все написано

нашел get_unmapped_area (без arch)

общего способа сделать то, что ты хочешь не существует.

но в некоторых случаях у тебя может это получиться.

возьми CONFIG_PAGE_OFFSET - максимальный размер стека - (для x86) VMALLOC_RESERVE - размер нужной тебе памяти - еще сколько нибудь на всякий случай

получишь адрес. мапь все на него в самом начале.

но это кривой хак и так писать нельзя.

> но это кривой хак и так писать нельзя.

Я буду писать на плюсах, где эти внутренности будут спрятаны, т.е. можно будет иметь билд как с настоящими указателями, так и с указателями через оффсет.

Но удивляет необходимость хаков для такой естественной технологии.

все альтернативы гораздо более противоестественны чем работа со смещениями.

гы-гы-гы! у меня все данные на 80% -- указатели

Значит надо что-то менять в консерватории :)

> гы-гы-гы! у меня все данные на 80% -- указатели

Ну и указывай в смещениях от начала области памяти. Зачем привязываться к конкретным адресам?