clone()?

Хм, посмотрю.. А может есть более переносимое решение? Я кстати не уверен что в моем ЯП без магии будет доступ к clone. Да и платформа сменится может..

> Можно ли сделать так, чтобы дочерний процесс не наследовал дескрипторы?

в линуксе? да, можно.

Кстати, clone вроде этого не умеет, флаг CLONE_FILES это нечто другое, и более того было бы удобнее запрещать наследовать не все|, а только некоторые дкскрипторы. скажем STDIN хотелось бы оставить, а соединие с базой прибить.

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

После получения очередной порции отфоркивается ребенок который эти данные как-то переваривает. После смерти демона родитель падает с ошибкой mysql gone away.

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

как?

> как?

man open
/O_CLOEXEC

Я всегда думал что это закроет дескриптор при вызове exec() ;)

> Я всегда думал что это закроет дескриптор при вызове exec() ;)

так и есть. ели ты знаешь свер™секретный®способ© порождения потомков без вызова fork+exec?

> ели ты знаешь свер™секретный®способ© порождения потомков без вызова fork+exec?

Хм, у ТСа ни слова про exec.

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

на вопрос отвечает К.О.

> Хм, у ТСа ни слова про exec.

зато у меня есть. почему? потому, что у ТСа есть много слов про дочерние процессы.

> потому, что у ТСа есть много слов про дочерние процессы.

Дочерний процесс никак не связан с exec. fork — это уже дочерний процесс.

Что касается архитектуры приложения ТСа... Ну может он форкается и передаёт управление в большой-пребольшой сторонний *.so. Мало ли извращений на свете. :)

> Дочерний процесс никак не связан с exec.

неужели?))))

Зачем тебе столько скобочек? Лиспер что ли?

> неужели?))))

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

> Дочерний процесс порождается форком.

а, ну в этом смысле да. но я что-то засомневался, что ТС имел в виду именно эти «внутренние» процессы, а не «внешние»…

Да, так точно, exec никак не связан с запуском дочернего процесса.. он запускает бинарники, а форк делает дочку..

>закрывает какой-то дескриптор, при закрытии дескриптора вызывается какой-нибудь деструктор,
Какая связь между дескрипторами и деструкторами кроме похожести слов? Дескрипторы - наследуются. Но их можно спокойно закрывать сразу после открытия без каких-либо последствий.

такая связь что у меня есть обьект класса DB_HANDLE который имеет деструктор, и когда я его закрываю, или когда он разрушается по выходе из области видимости, или когда программа заканчивает работу, etc вызывается деструктор, который отключает мне родитель (он пишет в дескриптор сообщение disconnect) ;)

Вот об этом я и говорил. Пляски с дескрипторами тебе не помогут, БД на том конце ничего не знает про твои процессы и дескрипторы, ей наплевать. Она закроет соединение как только получит соответствующее сообщение.

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

Ну о чем и речь. Проблема не в наследовании дескрипторов, а в том, что у тебя вызывается деструктор объекта.
Соответственно, решение номер один - добавить в объект метод для его «обезвреживания», так, чтобы деструктор не закрывал соединение.
Вариант два - вызвать exec() сразу после fork().
Вариант три - если объект типа DB_HANDLE автоматический, то можно завершать программу «нечестно» - вызывая exit(). При этом не вызываются деструкторы для автоматических объектов.

> Вариант четыре — исправить архитектуру приложения, чтобы кто попало не закрывал соединения к базе данных.

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