fork или ?

так, типа, освобождать при успешном создании в каждом дочернем процессе.

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

Применяешь механизм fork-and-exec то есть отделяешь код child'а в маленькую прогу и после fork'а делаешь exec ее.

?? Когда выполняется системный вызов fork -- порождённый процесс наследует _весь_ контекст процесса родителя. Собственно потомок отличается от предка только возращённым значением системного вызова. А вот вызвав ехес можно заместить контекст порожденного новым контестом... Можно разве что действительно освободить динамические переменные !

После exec-а весь сегмент данных будет заменен. Никаких старых динамических структур не останется и в помине.

сам же написал "мне на фиг не нужны". Если нужны то можно их передать через shared memory то есть будет процесс родитель отображать в shared memory нужные структуры а смещение передашь через FIFO потом приведешь к тому что тебе нужно, будешь жить при певаючи. :-))

Эти "5 метров переменных" никак не мешают. Благодаря механизму copy-on-write, в потомке(ах) эти переменные не займут дополнительной памяти, если только ты не начнешь изменять их. Попытка освободить динамически выделенную память в потомке не только бесполезна, но и вредна. Бесполезна, т.к. free() не возвращает память системе. Вредна, т.к. при освобождении памяти ты изменишьь copy-on-write страницы и система создаст их копию, отняв физическую память.

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

to dg. Не подскажешь где можно почитать про этот механизм и вообще про механизмы управления памятью?

можно clone() юзать с флагом CLONE_VM - в мане подробно все описано