https://www.opennet.ru/openforum/vsluhforumID9/8176.html Есть достаточно сложное многопотоковое приложение. Оно должно иногда запускать дочерние процессы и контролировать их выполнение. Возникает такая ситуация: по TCP этому приложению отправляется запрос, на который оно успешно fork'ает ребенка, отвечает `ok' и закрывает сокет. Проблема в том, что сокет не закрывается, по всей видимости из-за того, что при fork дескриптор сокета наследуется. Вопрос: как корректно закрыть все родительские дескрипторы в ребенке?<br><br>1. Вести учет открытых файловых дескрипторов по всему приложению я, разумеется, не собираюсь, по этой же причине никаких FD_CLOEXEC.<br>2. Нужно кроссплатформенное решение. Есть unshare, но это только Linux; есть rfork, но это только FreeBSD.<br> https://www.opennet.ru/openforum/vsluhforumID9/8176.html#10 Sun, 29 Mar 2009 13:35:55 GMT &gt;Закрой в себе сначала всё плохое и ненужное, а потом делай детей. <br><br>Универсальный ответ. Напиши его во все темы на этом форуме и застрелись, идиот :))<br> https://www.opennet.ru/openforum/vsluhforumID9/8176.html#9 Fri, 27 Mar 2009 20:08:00 GMT &gt;shutdown не то. Нужно _закрыть_ в ребенке все, кроме 0,1,2.<br><br>Закрой в себе сначала всё плохое и ненужное, а потом делай детей.<br> https://www.opennet.ru/openforum/vsluhforumID9/8176.html#8 Fri, 27 Mar 2009 14:39:47 GMT &gt;Не следить за дескрипторами это и есть 'угрёбищное' решение. <br>&gt;<br>&gt;Использовать для всех управляемых дескрипторов флаг FD_CLOEXEC, это нормальное корректное решение. Ни <br>&gt;разу не костыль.<br><br>Это именно костыль, потому закрывать или не закрывать дескрипторы при exec - это исключительно дело кода, вызывающего exec, а не кода, работающего с этими дескрипторами. Простой пример - после форка я могу exec'нуть как кусок себя, который ожидает открытый 3, так и стороннюю программу, где должно быть закрыто все. И что, cloexec или не cloexec?<br><br>Про чужой код я уже упомянул - ваши `следует предпринять попытки' из области фантастики.<br> Вы предлагаете лезть во _все_ компоненты, и втыкать туда fcntl, тогда как решение - закрывать или не закрывать, принимается все равно перед fork'ом или exec'ом.<br><br>&gt;// в случае отсутствия getdtablesize() можно использовать макрос MAX_FD <br>&gt;for (int i_fd = getdtablesize()-1; i_fd &gt; 2; --i_fd) close(i_fd); // оставили 0,1,2<br><br>Да, мне это по началу казалось костылем, но, видимо, так оно и д https://www.opennet.ru/openforum/vsluhforumID9/8176.html#7 Fri, 27 Mar 2009 13:29:56 GMT &gt;&gt;Не зря :) автор же написал:<br>&gt;&gt;&gt;1. Вести учет открытых файловых дескрипторов по всему приложению я, разумеется, не<br>&gt;&gt;&gt;собираюсь, по этой же причине никаких FD_CLOEXEC. <br>&gt;<br>&gt;Вы что же, не согласны, что это угрёбищное решение? Хотя бы потому, <br>&gt;что в проекте используются закрытые библитеки, которые файлы открывают, а вот <br>&gt;впихнуть в них fcntl - звиняйте. Поэтому я просил решение, а <br>&gt;не костыль. <br><br>Не следить за дескрипторами это и есть 'угрёбищное' решение.<br><br>Использовать для всех управляемых дескрипторов флаг FD_CLOEXEC, это нормальное корректное решение. Ни разу не костыль.<br><br>Для неуправляемых по какой-либо причине дескрипторов следует предпринять попытки сделать их управляемые и далее см. выше. Иначе возможно использование следующего приема:<br><br>// в случае отсутствия getdtablesize() можно использовать макрос MAX_FD<br>for (int i_fd = getdtablesize()-1; i_fd &gt; 2; --i_fd) close(i_fd); // оставили 0,1,2<br><br>А также есть интересный для изучения каталог /proc/self/fd, но он может быть не везде.<br><br>Прием https://www.opennet.ru/openforum/vsluhforumID9/8176.html#6 Fri, 27 Mar 2009 13:09:55 GMT &gt; Нужно _закрыть_ в ребенке все, кроме 0,1,2.<br><br>Можно посмотреть свой RLIMIT_NOFILE и пробежаться в цикле, всё поcloseить.<br>Смутно припоминается, что это как-то вроде можно побыстрее сделать, но не могу вспомнить.<br> https://www.opennet.ru/openforum/vsluhforumID9/8176.html#5 Fri, 27 Mar 2009 12:51:35 GMT &gt;Не зря :) автор же написал:<br>&gt;&gt;1. Вести учет открытых файловых дескрипторов по всему приложению я, разумеется, не<br>&gt;&gt;собираюсь, по этой же причине никаких FD_CLOEXEC. <br><br>Вы что же, не согласны, что это угрёбищное решение? Хотя бы потому, что в проекте используются закрытые библитеки, которые файлы открывают, а вот впихнуть в них fcntl - звиняйте. Поэтому я просил решение, а не костыль.<br> https://www.opennet.ru/openforum/vsluhforumID9/8176.html#4 Fri, 27 Mar 2009 12:43:46 GMT &gt;1. Есть shutdown()<br>&gt;2. п. 1 не спасёт от небходимости закрывать дескриптор в parent --- <br>&gt;иначе потекут дескрипторы, а это ограниченный ресурс.<br><br>shutdown не то. Нужно _закрыть_ в ребенке все, кроме 0,1,2. TCP соединение обрабатывается в родителе, в котором все, что нужно, закрывается.<br><br>&gt;3. Аффтору убить себя ап стену. <br><br>Детский сад...<br> https://www.opennet.ru/openforum/vsluhforumID9/8176.html#3 Fri, 27 Mar 2009 10:33:15 GMT &gt;&gt;3. Аффтору убить себя ап стену. <br>&gt;<br>&gt;Зря вы так. С клиентским сокетом действительно всё просто: форкнулись, в родительском <br>&gt;процессе закрыли, в дочернем общаемся с клиентом. Но есть интересный момент <br>&gt;с другими файлами, которые могли наоткрываться в родительском процессе, особенно в <br>&gt;других потоках. Они останутся в дочернем. Вроде как не особо и <br>&gt;мешает это, но всё же лучше бы их тоже закрывать. <br><br>Не зря :) автор же написал:<br>&gt;1. Вести учет открытых файловых дескрипторов по всему приложению я, разумеется, не<br>&gt;собираюсь, по этой же причине никаких FD_CLOEXEC. https://www.opennet.ru/openforum/vsluhforumID9/8176.html#2 Fri, 27 Mar 2009 08:19:12 GMT &gt;3. Аффтору убить себя ап стену. <br><br>Зря вы так. С клиентским сокетом действительно всё просто: форкнулись, в родительском процессе закрыли, в дочернем общаемся с клиентом. Но есть интересный момент с другими файлами, которые могли наоткрываться в родительском процессе, особенно в других потоках. Они останутся в дочернем. Вроде как не особо и мешает это, но всё же лучше бы их тоже закрывать.<br>