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

Месье знает толк в извращениях?

Вот и непонятно куда же я заглянул... =)))

Что за истерика?

Читая отдельных комментаторов (например, Вас) я понимаю что у тараканов в моей голове просто неистовые овации, плавно переходящие в истерику в зале, да. От хохота. =)))

Вы что, прямо с курсов кройки и шитья к нам заглянули?

Вот я и недоумеваю с какого перепоя в 2021г. приходится объяснять разницу между реализацией стека и stack segment.

Если бы Вы были в состоянии прочесть хоть что-либо, то уже нашли бы наверное в себе силы открыть первую же Вашу ссылку и в ней код https://github.com/hnes/libaco/blob/master/aco.c:

aco_share_stack_t* p = (aco_share_stack_t*)malloc(sizeof(aco_share_stack_t));
    assertalloc_ptr(p);
    memset(p, 0, sizeof(aco_share_stack_t));

    if(guard_page_enabled != 0){
        p->real_ptr = mmap(
            NULL, sz, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0
        );

Даже этого кусочка кода хватает чтобы задать простой вопрос – Вы где здесь работу со stack segment-то узрели? Здесь либо работа с heap (на это неиллюзорно намекает наличие malloc()), либо анонимное отображение в память (на что неиллюзоно намекает mmap()). Но ни там, ни там нет работы с сегментом стека в явном виде. Передача праметров тут не в счёт, т.к. это чисто служебная вещь и от Вас она не зависит.

Батенька, Вы всерьёз думаете что найденная Вами говнина про короутины кому-то интересна? Спешу Вас разочаровать – к теме треда она не относится, да и оттоптались на этой теме все кому не лень, ещё со времён Д. Кнута. Конкретнее вот здесь уже написано – C++: Выделение массива памяти 1Гб в куче или в стеке? (комментарий)

Как корутины (про них ещё Дональд Кнут в незапамятно-лохматом году писал в своей книге «The Art of Computer Programming», если что), так и фидеры и green threads это потоки исполнения в userspace. Т.е., ядро об этих потоках вообще ничего не знает и знать не желает. Рекомендую к прочтению и к ознакомлению парочку из вариантов реализации – GNU Pth и protothreads.

Т.е., Вы действительно считаете что наблюдать за попытками выдать реализацию стека за работу со stack segment это не потешно? Да от хохота сдохнуть можно! =)))

Какой же ты глупый.

Сам придумал себе разговор про сегмент стека, сам в нем участвует в своем воображении.

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

Ознакомьтесь с исходным постингом ТС, пожалуйста.

Какая часть первого же предложения Вам не понятна и вызывает сомнения? Вот этого вот:

Вот когда то давным давно, было не правильным выделять много памяти в стеке. Сначала даже не было динамических массивов.

Да, динамические массивы это про stack segment, да, выделение памяти в стеке это про stack segment, а не про ту ахинею, которую Вы зачем-то нагуглили и сюда приволокли.

Т.е., бестолочью себя выставляете Вы, а виноват в этом я? =)))

Стек при запуске точно так же mmap-ится системой, а не берется откуда-то МАГИЕЙ. Заммапь вручную сколько надо, и будет тебе стек.

Понятие динамической аллокации не существует в отрыве от понятия времени исполнения, когда выполнена эта аллокация.

Так-то почти вся оперативная память на уровне ядра аллоцируется и освобождается динамически.

я тоже считаю, что рекурсия не нужна

stack segment

Кстати в Win16 и OS/2 (по крайней мере 16 битной версии) был настоящий сегмент стека со своим селектором, но при этом он задавался в исполняемом файле также как и другие сегменты (код, данные) и можно было настроить любой размер стека. Ядро стека по умолчанию не создавало. В заголовке исполняемого файла (NE и LX) рядом с точкой входа (CS:IP) был far-указатель на стек задачи (SS:SP).

выделение памяти в стеке это про stack segment

Нет. Выделение памяти на стеке — это выделение в памяти, на которую в данный момент указывает ESP/RSP. Сам блок памяти для стека мог быть выделен ядром при создании потока или через mmap/malloc, значения это не имеет. alloca, SUB ESP, <size> будут везде работать.

я тоже считаю, что рекурсия не нужна

Эмм... я-то так не считаю )

Наоборот, стек для того и нужен, чтобы вкручивать/раскручивать. push/pop - и больше ничего не надо делать со стеком.

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

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

Как-то так )

Но вообще - хорошая тема получилась. Добавил в избранное. Много нового, интересного узнал )

Нет.

Ешё раз. Медленно и печально…

Стек при запуске точно так же mmap-ится системой, а не берется откуда-то МАГИЕЙ. Заммапь вручную сколько надо, и будет тебе стек.

Ни какой магии. В образе elf-файла есть сегмент GNU-stack с нулевым размером. Т.е., система в курсе что стековый сегмент есть. Но, т.к. один и тот же бинарь может исполняться в разных системах, то при старте процесса система выделит этому бинарю стек такой, какой определён в её рамках и согласно ulimits. Где-то это может быть 8К, где-то это может быть 10К.

Т.е., Вы можете скомпилить бинарь на системе, где выставлено 10К и запустить в системе с 8К или наоборот.

Использовать mmap() или анонимное отображение в память здесь ненужно. Для работы с сегментом стека есть динамические массивы и ф-я alloca(). Для увеличения размера стекового сегмента процесса есть setrlimit(). Всё. Путать одно с другим не нужно.

Понятие динамической аллокации не существует в отрыве от понятия времени исполнения, когда выполнена эта аллокация.

Да, мой Капитан… =))) Вот только есть одно маленькое «но».

Так-то почти вся оперативная память на уровне ядра аллоцируется и освобождается динамически.

glibc дефолту не возвращает память системе. Ни в stack segment, ни в heap. О причинах выше писал – если через тот же malloc() запросить гектар памяти, отработать там данные, потом сделать free(), то вовсе не факт что освобождённая память сразу же поступит в распоряжение системы. Скорее всего, она останется закреплённой за процессом, т.к., если мы раз запросили такой объём памяти, то скорее всего такой же объём памяти может понадобиться вновь, но чуть позже.

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

И нет, mmap() не при делах. Эта память резервируется и, что самое важное, гарантированно возвращается системе после munmap().

В OS/2 и в 32-х разрядной, ЕМНИП, было.

Кстати в Win16 и OS/2 (по крайней мере 16 битной версии) был настоящий сегмент стека со своим селектором, но при этом он задавался в исполняемом файле также как и другие сегменты (код, данные) и можно было настроить любой размер стека. Ядро стека по умолчанию не создавало. В заголовке исполняемого файла (NE и LX) рядом с точкой входа (CS:IP) был far-указатель на стек задачи (SS:SP).

Если я не ошибаюсь насчёт «полумухи». Давненько это было. Только толку-то с этого что? Мы ту не про «полумуха» рзговариваем, а про Linux же.

/* От себя замечу что и Warp и Merlin были вполне-вполне, да и компиль, которым я в те времена пользовался, Watcom C/C++ 10.0 тоже, т.к. я по большей части тогда писал под QNX, OS/2, Novell тоже был вполне достойным. Но те времена уже прошли. Linux во все поля. Теперь это всё уже из разряда «старики вспоминают». */

В образе elf-файла есть сегмент GNU-stack с нулевым размером.

Кто тебе сказал, что на целевой платформе вообще ELF? В POSIX об этом ни слова. А если завтра придумают формат, в котором запись в таблице исполняемого файла будет называться не «сегмент», а «кукарек», ты будешь рассказывать про «стековые кукареки»?

Т.е., система в курсе что стековый сегмент есть.

Это какое-то представление о работе с памятью из 87-го года.

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

Выше тебе X512 правильно пишет, что куда регистр стека указывает, там у программы и стек. Только ты слушать не хочешь.

malloc()

Можно подумать, не через mmap() выделяет память под кучу.

В том-то и дело что имеет.

Сам блок памяти для стека мог быть выделен ядром при создании потока или через mmap/malloc, значения это не имеет.

Выше уже задолбался объяснять почему имеет и ещё как имеет.

Можно подумать, не через mmap() выделяет память под кучу.

Есть древний sbrk который ещё используется в некоторых дистрибутивах.

Ну в таком разе понятно, почему у него система не освобождает гигабайтные куски :)

Выше уже задолбался объяснять почему имеет и ещё как имеет.

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

Ну в таком разе понятно, почему у него система не освобождает гигабайтные куски :)

Стати даже в Win16 выделение памяти прогрессивнее sbrk, там всё выделяется и освобождается динамически в глобальной куче и есть система подкачки. sbrk — это какой-то архаизм первых UNIXов.

PE-шечка:

SizeOfStackReserve — The size of the stack to reserve. Only SizeOfStackCommit is committed; the rest is made available one page at a time until the reserve size is reached.

SizeOfStackCommit — The size of the stack to commit.

И никаких вам эльфов с сегментами.

В Windows вообще все стеки выделяются аналогом mmap: BaseCreateStack. Там же обработка полей PE-заголовка SizeOfStackReserve/Commit. Нет никакого «сегмента стека».

А можно полюбопытствовать? =)))

Есть древний sbrk который ещё используется в некоторых дистрибутивах.

Чем же сейчас модно и идеологически более правильно? Ессичо, я там выше уже показывал чем именно пользуется malloc() в используемом мною дистрибутиве.

uname -a:

Linux [неважно] 5.11.0-gentoo-x86_64 #1 SMP Mon Mar 1 00:29:09 MSK 2021 x86_64 [неважно] GenuineIntel GNU/Linux

gcc --version:

gcc (Gentoo 10.2.0-r5 p6) 10.2.0

ldd --version:

ldd (Gentoo 2.32-r8 p8) 2.32

И насколько же древний этот ваш sbrk()? Если для той же macOS этот сисколл пришлось эмулировать и он там максимум 4М может зарезервировать. А так-то в современных Linux, всё от объёма запрашиваемой к выделению памяти. Где-то работы malloc() и через sbrk() достаточно, а где-то и через mmap() придётся.

ХДЕПРАСТИТИ?!?

В Windows

Вы сайтом, часом, не ошиблись? Кого же здесь интересует что там в Windows?

Чем же сейчас модно и идеологически более правильно?

Через mmap. И освобождать память, когда на блоке, выделенным mmap, не осталось блоков, выделенных malloc.

sbrk and brk are considered legacy even by 1997 standards (Single UNIX Specification v2 or POSIX.1-1998). They were removed in POSIX.1-2001.

Отсюда. Его из некоторых дистрибутивов Линукса уже выпиливают.

push/pop - и больше ничего не надо делать со стеком.

В современных архитектурах процессоров (например RISC-V) вообще нет push/pop, вместо этого делается примерно так:

00012064	1101 	ADDI SP, SP, -32
00012066	EC06 	SD RA, 24(SP)
00012068	E822 	SD FP, 16(SP)
0001206A	E426 	SD S1, 8(SP)
0001206C	E04A 	SD S2, 0(SP)

Чё, серьёзно штоль?

PE-шечка:

То Вы пытаетесь съехать на POSIX (зачем-то, ща ещё за это «выхватите комплиментов», в другом комменте). То Вы волочёте на мой linux.org.ru винюковые спеки зачем-то и что-то через эту говнину пытаетесь доказать? Зачем? Я и так в курсе что PE-files то говно, которое ещё с DOS-headers никак не расстанется, а это уже ближе к археологии, а не к программированию, т.к. это уже культурный слой где-то в районе «говно мамонта».

Если это вся Ваша аргументация, то надо ли Вам что-то говорить? Вы сами-то подумайте? =)))

Я и так в курсе что PE-files то говно, которое ещё с DOS-headers никак не расстанется, а это уже ближе к археологии, а не к программированию, т.к. это уже культурный слой где-то в районе «говно мамонта».

Скорее ELF — это кривой переусложнённый формат, провоцирующий коллизию символов и трудноотлавливаемые баги. Только относительно недавно ввели symbol versioning, который частично решает проблему через костыли. А в Windows ещё в Win16 формат исполняемых файлов был грамотно спроектирован не говоря о Win32. Что характерно, в UNIX сертифицированной системе Mac OS используется свой грамотно спроектированный формат исполняемых файлов Mach-O, в котором нет коллизии символов и костылей.

говнина

говно

говно

аргументация

Продолжай. Очень интересно.

Выше был короткий код.

Скажите, почему там sbrk()?

Его из некоторых дистрибутивов Линукса уже выпиливают.

Бууугага! =))) «Имя, имя, сестра!» © к/ф «Три мушкетёра»? Кто же эти смельчаки, которые его выпиливают? Хотелось бы знать этих достостлавных «некоторых дистрибутивов», в особенности, если учесть что glibc используется в mainstream и даже в musl, на которую Вы столь неловко ссылались выше (да, я знаю где Вы раздобыли часть исходников – сырцы musl, uClibc, newlib я в состоянии распознать =))). Так вот, даже в musl присутствует вызов brk(). Как внутренняя реализация, но да, он есть. Ни кто его почему-то не выпиливает никуда. Странно, да? И вот всё остальное – тот же #define MMAP_THRESHOLD в полный рост. Т.е., как я говорил – где-то через brk()/sbrk(), а где-то через mmap(). Зависит не от Вашего желания или нет, а от требуемого объёма памяти.

sbrk and brk are considered legacy even by 1997 standards (Single UNIX Specification v2 or POSIX.1-1998). They were removed in POSIX.1-2001.

«Проблема людей в том, что они с лёгкостью верят всему, написанному в Интернет» ©В. И. Ленин.

И да, это я уже издеваюсь. =)))

Ясно.

Продолжай. Очень интересно.

Мы все помним от отцов и дедов заповедованное правило ведения инторнет-диспутовЪ – нефиг по теме сказать, так докопайся до аргументации или личности собеседника. Огггадааа… =)))

Я всё понял, не продолжайте, ненадо. Хотя, там я Вам пообещал небольшую порку, ну чтож… Придётся исполнять. За язык я лично Вас не тянул. =)))

Вкусовщина. Вообще-то... =)))

ELF — это кривой переусложнённый формат, провоцирующий коллизию символов и трудноотлавливаемые баги.

У меня в Linux elf не провоцирует коллизий символов даже для MIPS. Не расскажите какие они, эти коллизии символов?

Трудноотлавливаемые баги? А какие они для elf, не расскажите? Вам же из Haiku хорошо видно?

Что характерно, в UNIX сертифицированной системе Mac OS используется свой грамотно спроектированный формат исполняемых файлов Mach-O, в котором нет коллизии символов и костылей.

Ну а какие же костыли есть в формате файлов elf?

Дык... =)))

Вы ещё не поняли что я вообще не про то говорил? =)))

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

Этот вопрос и не обсуждался. Пока я Вам выписывал за то, что Вы имели наглость спутать stack segment и собственноручно нарукоблуженную реализацию стека.

А программа самостоятельно стека не выделяет. Она только корректирует то, что ей система уже выделила по дефолту. Вы даже не понимаете о чём речь, да? И в чём разница? =)))

Скажите, почему там sbrk()?

Чтобы работал легаси говнокод, который напрямую использует sbrk. Если sbrk отключён, то будет использоваться mmap.

Вот дискуссия про устаревшесть и ненужность sbrk от авторов musl.

Based on a discussion on IRC, we’re thinking about removing support for the legacy sbrk and brk functions. These functions are fundamentally broken and unfixable: For an application to use them correctly, it must depend on the malloc subsystem never being used, but this is impossible to guarantee since malloc may be used internally by libc functions without documenting this to the application.

А программа самостоятельно стека не выделяет.

Если захочет (например размера стандартного стека мало и нет root доступа), то без проблем выделяет.

Вы даже не понимаете о чём речь, да? И в чём разница? =)))

Разница только в том, что так называемый вами «сегмент стека» выделило ядро при создании процесса, а свой стек выделила программа через mmap/malloc. Функционально эти 2 стека ничем не отличаются, все библиотеки, включая libgcc_s/libunwind будут работать на любом из них.

Я обещал Вам "порку"? Извольте... =)))

Кто тебе сказал, что на целевой платформе вообще ELF? В POSIX об этом ни слова.

Т.е., издав вот этот вот вопль про POSIX Вы подумали что Вы меня впечатлите? =))) Вообще-то, нет.

Для того, чтобы ссылаться на POSIX как на семейство стандартов, нужно две вещи:

• Самому прочесть их.
• Быть уверенным что собеседник их не читал.

Судя по всему, в Вашем случае ни того, ни другого нет. Так вот. У меня для Вас крайне хреновая новость. POSIX ни где, ни как, ни единой буквой не гарантирует двоичную (бинарную) совместимость между системами. Совместимость на уровне исходных кодов он да, гарантирует, т.к. для того и писался. И то ещё уровень соответствия надо смотреть, т.к. тот же столь любимый Вами оффтоп до некоторой степени тоже POSIX-совместимая система. По крайней мере, это «POSIX + внутрикорпоративные стандарты» или 4-й уровень соответствия. Назвать оффтоп полностью POSIX-compatible системой руки не поворачиваются. Но пока Вы пишете с использованием POSIX API (что же тут можно написать я и не спрашиваю), Ваш код будет относительно POSIX-совместим. Детали реализации тут так же не важны, т.к. поведение того же select() в оффтопе и онтопе или *BSD будет слегка различно (подсказка – см. первый параметр select()). Но Вы можете использовать select() в любой POSIX-совместимой системе даже не думая о различиях.

А вот бинарную совместимость нет, к Вашему сожалению, POSIX не гарантирует. Отсюда следует то, что Ваш этот жалкий вскрик насчёт POSIX и elf или pe или ещё какой формат исполняемых файлов, к делу не относится вообще ни как. К Linux, кстати, тоже.

Это какое-то представление о работе с памятью из 87-го года.

Секс вообще-то не изменился с момента появления Homo Sapiens и ничего. Как-то справляемся с нехитрым делом продолжения рода… =))) Пороху вот уже тоже порядка 5000 лет и ни на что не поменяли. Зачем безумно кидаться чинить то, что и так работает?

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

Мимо. Понимаю, даже как-то стыдно Вас отправлять маны курить… Но прочтите что-нибудь про анонимные области памяти и сегмент стека. И тут не важно – у процесса или у потока.

Выше тебе X512 правильно пишет, что куда регистр стека указывает, там у программы и стек. Только ты слушать не хочешь.

Потому что до него даже не доходит что он пишет ху… «ерунду», в общем. =))) Так бывает.

Можно подумать, не через mmap() выделяет память под кучу.

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

Опять нет.

Если захочет (например размера стандартного стека мало и нет root доступа), то без проблем выделяет.

Угу. В случае с динамическими массивами да, поменяет. Ну или используйте setrlimit() без рутового доступа чтобы прямо вот так взять и поменять не косвенно, а напрямую. И без установки CAP_SYS_ADMIN или CAP_SYS_RESOURCE. Оггада… =)

Разница только в том, что так называемый вами «сегмент стека» выделило ядро при создании процесса, а свой стек выделила программа через mmap/malloc. Функционально эти 2 стека ничем не отличаются, все библиотеки, включая libgcc_s/libunwind будут работать на любом из них.

Гонево.

POSIX ни где, ни как, ни единой буквой не гарантирует двоичную (бинарную) совместимость между системами.

Вот открытие-то. Дон Кихот?

Отсюда следует то, что Ваш этот жалкий вскрик насчёт POSIX и elf или pe или ещё какой формат исполняемых файлов, к делу не относится вообще ни как. К Linux, кстати, тоже.

Это ты про свои кукареки насчёт сегментов эльфа? Самокритично.

POSIX ни где, ни как, ни единой буквой не гарантирует двоичную (бинарную) совместимость между системами.

Про «сегменты стека» он тоже ничего не говорит.

Нууу... =)))

Вот открытие-то. Дон Кихот?

Должен же хоть кто-то заняться Вашим после-ГПТУшным образованием? «ВУЗовским» образованием то, что с Вами сделали, не назовёшь… Пусть это буду я. Так и быть. =)))

Это ты про свои кукареки насчёт сегментов эльфа? Самокритично.

readelf -a ./mem |grep GNU_STACK
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000

readelf с Вами не согласен. Ну и далее по треду.

Ладно. Я и так всё насчёт диалога с Вами понял. То, что Вы думаете что Вы что-то там понимаете в программировании на С или в форматах файлов, это поиск луж – типа а вот в оффтопе вот так… Смотреть на Ваши попытки хоть где-то найти лужу чтобы её потом газифицировать уже с души воротит. Ну что, на … как Вы правильно поняли, в игнор? =))) Один чёрт у Вас там какая-то альтернативная реальность.

Ну и да – man setrlimit конечно же.

А должен

Про «сегменты стека» он тоже ничего не говорит.

?

readelf с Вами не согласен. Ну и далее по треду.

Program table содержит не только сегменты (PT_LOAD), но и разные флаги и указатели на таблицы (PT_DYNAMIC, PT_INTERP, PT_GNU_EH_FRAME). PT_GNU_STACK — это просто флаги защиты памяти стека (в ядре), эта запись не имеет отношения к сегменту стека, адреса и размеры игнорируются.

Возможно Вам сложно понять...

Но в той ссылке, на которую Вы сослались, сразу сказано:

/* Check if the stack is nonexecutable. */

Т.е., stack segment уже есть, его проверяют на неисполняемость.

эта запись не имеет отношения к сегменту стека, адреса и размеры игнорируются.

Бггг… ЛОЛШТА?!? =)))

P.S. И, кстати, да. Зачем Вы приволокли сюда поддержку dynamic link library, это вообще не ясно. Там нагуглилось? =)))

Бггг… ЛОЛШТА?!? =)))

Попробуйте задать адрес и размер в PT_GNU_STACK и посмотрите на карту памяти процесса. Сегменты — это только PT_LOAD.

Извините.

Попробуйте задать адрес и размер в PT_GNU_STACK и посмотрите на карту памяти процесса. Сегменты — это только PT_LOAD.

Я уже рассказал как задаются размеры стека для процесса в Linux.

Я уже рассказал как задаются размеры стека для процесса в Linux.

Но не через PT_GNU_STACK, так что это не сегмент, а флаги. В ELF нет сегмента стека, как и в прочих современных форматах. Он есть в NE (Win16) и LX (OS/2).

Я вам вот уже вторую страницу объясняю...

Что сегмент стека в случае создания процесса ЕСТЬ. Здесь же просто есть указание на то, что сегмент стека ЕСТЬ. Как внутри elf-файла, Вам это 300 лет подряд неважно.

Гонево.

Я вам уже давал код для запуска программ в своём стеке, даже адаптировал его чтобы он у вас запускался. Можете хоть главный GUI поток Qt/GTK использующий исключения из SwitchStack запускать.

Здесь же просто есть указание на то, что сегмент стека ЕСТЬ.

Какое-то странное указание, стек и без PT_GNU_STACK прекрасно создаётся ядром. Это просто флаги.

Нет.

Вы не давали никакого «своего стека». Вы дали реализацию на malloc(), которая ни как не относится к сегменту стека. И, кстати, довольно кривую.

Ну и как же создаётся...

Какое-то странное указание, стек и без PT_GNU_STACK прекрасно создаётся ядром. Это просто флаги.

То, чего с Ваших же слов нет?

Можно если хочется там где это возможно, но ненужно ибо проблем больше чем профитов. А вот маленькие кусочки внутри функций через alloca дёргать это прекрасно, не надо освобождать аллоцируется молниеносно и доступ 50 на 50 конечно, но часто быстрее чем из кучи тянуть.

То, чего с Ваших же слов нет?

Я не говорю, что «сегмента стека» нет, я говорю что в нём нет ничего особенного по сравнению с mmap и пользоваться им не обязательно.