Си, fork() и глобальные переменные

У процессов разные адресные пространства.

Это безопасно?

Мусор безопасен?

Запихни их всех в одну глобальную структуру и подмени.

безопасно
/thread

понимаю что мусор, но так не хочется перебирать чужой уже рабочий код...

но так не хочется перебирать чужой уже рабочий код.

Так не перебирай, никто не заставляет. Но и вопросы не задавай, всё-равно ничего делать то не собираешься. Верно?

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

Память процесса копируется (на самом деле cow), те остаётся как на момен до вызова fork().

Короче, порядок не ясен

Так. Вызываю телепатов и Кашпировских. Срочно надо наванговать код ТС.

Та он тупо не понимает как fork() работает.

Там есть нюансы. Читай хорошую литературу по применению fork. Имею в виду, что если там в примерах будет вызов printf в дочернем процессе до загрузки другого образа, то это уже неправильные примеры, хотя для иллюстрации годятся, если авторы предупредили об этом. Там все непросто из-за сигналов.

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

Всё ок. Там будет copy-on-write на уровне страниц памяти (обычно 4кб). У нового процесса страницы будут помечены как read-only, во время записи будет page fault. В этот момент ядро за тебя склонирует страницу и продолжит исполнение в новой странице.

extern

Ваще, с этим fork связаны некоторые ранние ошибки, допущенные при проектировании POSIX. Со временем набили шишки, и сейчас примерно понятно, что можно делать, а что нельзя в дочернем процессе. Обычно безопасно что-то прочитать с каналов, а затем загрузить новый образ в дочерний процесс. Все остальное надо рассматривать под очень большой увеличительной лупой, потому что код должен быть безопасен относительно сигналов. Есть очень ограниченный список функций, которые можно безопасно вызывать.

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

а такой общий вариант вариант:

void any_func() {

pid_t pid;

//этот массив создается на стеке
char any_str_param[MAX_LEN_CHEGO_TO_TAM];
strcpy(any_str_param, "param_value");


//тут дитя
if(!pid) {

  ececl(
    BINPATH_STR,
    BINNAME,
    char any_str_param, //массив на стеке от родителя
    NULL
  );

}

return;

}

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

Это вы с кодом внутри обработчиков сигналов попутали. После fork() в дочернем процессе использовать мьютексы можно и безопасно (если вы, конечно, не пытаетесь делать что-то типа разблокировки мьютекса, заблокированного перед форком родительским процессом).

Если ты берешь *.c файл, в котором статиком объявлена переменная, для которой есть функции реиниализации — все ок. Если нет, рано или поздно будет срань.

P.S. Подразумевается, что деинит не будет модифицировать внешнее окружение (файлы, сущестующие состояния на удаленных узлах и прочие шареные ресурсы).

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

Всё ок. Там будет copy-on-write на уровне страниц памяти (обычно 4кб). У нового процесса страницы будут помечены как read-only, во время записи будет page fault. В этот момент ядро за тебя склонирует страницу и продолжит исполнение в новой странице.

это показало мне уровень моей некомпитентности

После fork() в дочернем процессе использовать мьютексы можно и безопасно (если вы, конечно, не пытаетесь делать что-то типа разблокировки мьютекса, заблокированного перед форком родительским процессом).

Ты точно ничего не напутал сам? Безопасно только после загрузки через execv (и подобные) в новом образе. Пока образ не загружен - опасно.

У меня был наглядный пример, когда серверный софт регулярно падал под нагрузкой из-за этой хрени. Как поправили, то стало работать как часы.

После execl может делать, что хочешь. Главное, между fork и execl быть очень осторожным! Только я не понял, как ты собрался передать данные через execl. Читай лучше документацию и меньше советуйся на ЛОРе.

Да, точно. Это вообще общепринятая практика в реализации серверов, состоящих из нескольких процессов. Да и вообще иначе и нельзя сделать многопроцессный сервер, кроме как делая fork(), но _не_ делая exec.

даннеы в execl передаются как локальные массивы созданные в родителе. Локальные переменные ведь должны иметь копии в процессе-потомке?

Сразу после fork - да, но обращение к ним не всегда безопасно, а вот после безопасного exec(*) - уже нет никаких данных. Если бы было все так просто, то fork давно бы перетащили во все языки программирования! Поэтому нужно продумать, как передавать данные. А ты думал заполучить все на халяву?! :)

Может, тебе многопоточность просто нужна?

взвешивал варианты с многопоточностью. у нее есть минусы которые определяютяс тем что у потоков общее адресное пространство. Например, сигфолт в чужом коде будет фатален для всего приложения, а если использовать fork+execl, то это более безопасно, но и велосипедно в плане отслеживания состояния другого процесса.

Ну, тут выбор - либо общие данные (многопоточность), либо изолированность (процессы). А кластерах пока не говорим.