Дочерний процесс может изменить родительское состояние epoll

0

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

У меня есть программа, объявляющая статический объект epoll (объект, который обертывает epoll):

static EventManager* evMgrPtr = NULL;

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

Дети делают совсем другое дело, однако программа НЕ делает fork/exec, а дети несут и запускают часть кода в одной и той же переводческой единице.

      pid_t pid = fork();
      switch(pid) {
      case -1:
        YREPL_LOG_FATAL("Couldn't start server process ");
        exit(EXIT_OK);

      case 0:
    #ifndef __FreeBSD__ 
        assert( closeThisFd != -1 );
        evMgr.unregisterSocketEvent( closeThisFd );
        close( closeThisFd );
    #endif
        close(outpipe[0]);
        close(errpipe[0]);
        dup2(outpipe[1], 1);
        dup2(errpipe[1], 2);
        close(outpipe[1]);
        close(errpipe[1]);

Проблема в том, что после того, как я evMgrPtr-> unregisterSocketEvent (closeThisFd) в дочернем процессе, я обнаружил, что родительская остановка также смотрит на прослушивающий сокет !!!

Может кто-нибудь пролить свет на то, почему это происходит. Я подумал, что когда вилка будет выполнена родителем, а дети будут делать КОВ. Итак, что бы ни делали дети с его копией объекта epoll, не должны отражаться в родительском праве?

  • 0
    Файловые дескрипторы уникальны в общем унаследованном пространстве процесса. Если вы хотите иметь независимую обработку от дочернего процесса, обратитесь к dup() пожалуйста.
  • 0
    Я не думаю, что я хочу dup () унаследованный fd. Все, что я хочу сделать, - это чтобы родитель продолжал слушать порт, не давая последующим разветвленным дочерним элементам прослушивать порт.
Теги:
epoll

1 ответ

0

Кажется, что вы используете цикл событий EPOLL -based. Таким образом, поскольку файловый дескриптор для самого epoll-объекта делится между дочерним и родительским, удаление дескриптора файла из epoll() -based дескриптора в дочернем также влияет на родительский процесс :). Пожалуйста, прочитайте man epoll, man epoll_create.

  • 0
    Как видно из фрагмента кода, этот код был перенесен из FreeBSD в RHEL. В реализации FreeBSD он использует kqueue, который, по-видимому, не будет разделять очередь через fork, как предложено на странице руководства. Существует ли подобный механизм событий для RHEL? Какие очереди событий не распределяются между родителями / детьми?
  • 0
    Согласно странице руководства epoll. «Всякий раз, когда дескриптор дублируется с помощью dup (2), dup2 (2), fcntl (2) F_DUPFD или fork (2), создается новый дескриптор файла, ссылающийся на то же самое описание открытого файла. Открытое описание файла продолжает существовать пока все файловые дескрипторы, ссылающиеся на него, не будут закрыты. Дескриптор файла удаляется из набора epoll только после того, как все файловые дескрипторы, ссылающиеся на описание открытого открытого файла, были закрыты (или до того, как дескриптор был явно удален с помощью epoll_ctl () EPOLL_CTL_DEL ) «.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню