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

Ваще, с этим 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() в дочернем процессе использовать мьютексы можно и безопасно (если вы, конечно, не пытаетесь делать что-то типа разблокировки мьютекса, заблокированного перед форком родительским процессом).

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

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

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

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

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

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

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

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

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

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