Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > C/C++: Программирование под Unix/Linux > [pipe] возможность прервать блокирующую операцию

Автор: cupper 15.3.2012, 22:33

Пытаюсь реализовать корректное завершение потока заблокированного на операции с pipe'ом. Первый вариант работа в лоб Код mkfifo(FIFO_FILE, 0666) handle_ = open(FIFO_FILE, O_READONLY); заблокируется на операции open до тех пор пока другой процесс не откроет pipe на запись. Прервать эту операцию на вряд ли получится. Я не нашел способа. Второй вариант, используем неблокирующий режим Код mkfifo(FIFO_FILE, 0666) handle_ = open(FIFO_FILE, O_RDWR | O_NONBLOCK); int flags; if ((flags = fcntl(handle_, F_GETFL, 0)) < 0) printf("ERROR: fcntl get\n"); flags &= ~O_NONBLOCK; if (fcntl(handle_, F_SETFL, flags) < 0) printf("ERROR: fcntl set\n"); fd_set rfds; FD_ZERO(&rfds); FD_SET(handle_, &rfds); if(select(handle_ + 1, NULL, &rfds, &rfds, NULL) == -1) Пояснение 1: после того как мы "открыли" pipe переводим его в блокирующий режим иначе каждая наша операция будет сразу возвращаться управление. Пояснение 2: используем select, но мы не можем использовать его для операции read так как она возвращает 0 на еще не открытом pipe, поэтому открываем pipe в оба режима, и блокируемся на операции write. Я было надеялся что операция write прервется если мы сделаем close(), но она не прерывается. Так же не появляется исключительная ситуация (для которой я попробовал установить 4 параметр select). Долго и усердно пытался найти как прервать select. Не нашел.  Вариант использования pselect плохой, так как я не могу послать сигнал в поток он шлется в процесс. Единственным вариантом пока вижу прерывать поток открытием pipe со второй стороны, ну и например записью туда какого нибудь значение по которому прерываемый поток узнает что это команда exit. Но и этот вариант мне не кажется хорошим.  Излазил весь интернет, все что нашел сведено в коде выше. PS. хммм, обнаружил такую функцию pthread_kill... неужели в лине можно послать сигнал конкретному потоку ?

Автор: xvr 16.3.2012, 11:47

Цитата(cupper @  15.3.2012,  22:33 ) Долго и усердно пытался найти как прервать select. Не нашел.  Открыть еще один pipe (анонимный) и подать его 2м handle'ом в select. Ну и записать в него что нибудь, что бы прервать select. Еще можно использовать eventfd вместо 2го пайпа (если у вас ядро >  2.6.22) Цитата(cupper @  15.3.2012,  22:33 ) используем select, но мы не можем использовать его для операции read так как она возвращает 0 на еще не открытом pipe, Попробуйте poll или epoll

Автор: cupper 16.3.2012, 20:52

Цитата(xvr @ 16.3.2012,  11:47) Открыть еще один pipe (анонимный) и подать его 2м handle'ом в select. Ну и записать в него что нибудь, что бы прервать select. Ну это по сути ненужное усложнение способа открыть пайп и записать туда что нибудь.  Цитата(xvr @ 16.3.2012,  11:47) Попробуйте poll или epoll И что изменится ? Повисну в нем так же как и в select. Уточните пожалуйста, что вы имели в виду под этим, я может вас не понял.

Автор: Fynivx 16.3.2012, 22:49

А нельзя использовать стандартные средства плюсов? condition_variable, например? Там есть метод, который может ожидать сигнала определенное время. А во втором процессе - посылать сигнал после открытия. Потоки уже стандартизированы в C++...

Автор: cupper 16.3.2012, 23:12

Цитата(Fynivx @ 16.3.2012,  22:49) А нельзя использовать стандартные средства плюсов? condition_variable, например? Там есть метод, который может ожидать сигнала определенное время. А во втором процессе - посылать сигнал после открытия. Потоки уже стандартизированы в C++... в винде я так и сделал, там есть Event и есть WaitForMultipleObject. В linux аналога нету. Есть select который умеет проверять что следующая операция (чтения, записи) не будет блокирующая. Есть pselect который еще умеет ждать сигнал (но сигналы то шлются все тредам, хотя есть pthread_kill но его работа для меня пока не очень ясна, да и сигнал это не средство синхронизации). Использовать TimeOut вообще плохая затея.  Но я не понял как вы предлагаете скрестить condition_variable и блокирующую open или write ? Это как раз то что нужно, вот только я не знаю возможно ли такое

Автор: Fynivx 17.3.2012, 00:19

Цитата(cupper @  16.3.2012,  23:12 ) как вы предлагаете скрестить condition_variable и блокирующую open или write ? Блокирующий - не знаю. А с неблокирующим возможно. По крайней мере, я представляю примерно так: Первый процесс создает и открывает очередь в неблокирующем режиме, после чего вызывает wait с таймаутом. Это для того, чтобы, если второй процесс так и не откроет соединение, первый не завис в бесконечном ожидании. Если сообщение было получено, начинается обмен. Если нет - очередь закрывается. А второй, опять же, открывает очередь, и посылает первому сообщение об открытии через notify. Как-то так. notify_one посылает сигнал одному процессу, notify_all - всем ожидающим. Вообще можно организовать очередь любого типа нативными средствами. По крайней мере, я бы так сделал. И никакой привязки к операционке не будет. Хм... Или у Вас привязка к C а не к C++? А можете описать задачу взаимодействия процессов в целом? Может, что проще придумается и без хэдеров windows и pthreads.

Автор: svlary 17.3.2012, 06:21

Цитата(cupper @  15.3.2012,  22:33 ) Прервать эту операцию на вряд ли получится.      А зачем ее прерывать ? Смысл pipe как раз и заключается в том, что СЕРВЕР должен повиснуть до тех пор, пока КЛИЕНТ не положит  свое сообщение в pipe.  Главная мысль : pipe должны использовать два (!) процесса. И один из них должен постоянно  висеть на чтении. Проще говоря - ждать прихода сообщения. И это абсолютно  нормальная логика клиент/серверных технологий. Зачем ее ломать изобретая деревянные велосипеды на треугольных колесах - я не понимаю.    Если же Вы хотите что бы и клиент и сервер запускались из одного исполняемого модуля, то можно сделать так : Код Главный процесс                                     Подчиненный процесс // Создаем pipe mkfifo(...) // Запускаем клиента fork(...)                                                                 // После подготовки, клиент хочет отправить сообщение серверу:                                                                 fw = open(..., O_WRONLY); // Клиент повис - ждет сервера // Управление передается в процесс сервера fr = open (..., O_RDONLY);   // Вот и встретились два одиночества... // Серовер повис на ожидании сообщения   read(fr,...);                                                                  // Управление вернулось в клиент - он пишет сообщение :                                                                 write(fw,...); // И занимается своими делами // Сервер соскакивает с read и обрабатывает поступившую команду. proccess_cmd(...); // И возвращается в начало ЦИКЛА чтения сообщений Для ознакомления с классикой программирования под Unix/Linux рекомендую хотя бы : Марк Дж Рочкинд. "Программирование для UNIX".

Автор: Fynivx 17.3.2012, 07:04

Цитата(svlary @  17.3.2012,  06:21 ) А зачем ее прерывать ? Бывают такие ситуации. Вот у меня, например, сейчас в одном проекте наблюдается следующая картина:  куча неконтролируемых сверху процессов работают с одной областью памяти, причем никто из них не знает, кто когда завершится или прервется. Нетрудно представить ситуацию, когда пара таких процессов, вместо использования общей памяти, общаются между собой пайпами. И тогда нужно предусмотреть ситуацию, когда один из них внезапно сломается. Но я, честно говоря, не могу представить ситуацию, где их использование выгоднее) Добавлено через 3 минуты и 31 секунду Даже для двух совершенно разных модулей, написанных на разных языках, можно сообразить шаред-мемори через dll'ку)

Автор: rsm 17.3.2012, 09:50

Цитата(cupper @  16.3.2012,  00:33 ) Долго и усердно пытался найти как прервать select. Не нашел Как один из самых элементарных вариантов: а) создаём маску сигналов, в которой заблокировано всё; б) назначаем эту маску процессу; в) удаляем из маски какой-то сигнал, к примеру SIGUSR1; г) висим на pselect; д) когда надо, сами себе оправляем заранее определённый сигнал (SIGUSR1); е) pselect завершается по прерванному системному вызову; Вариант другой, более годный: вынести обработку сигналов в отдельный поток. Делать такое необходимо, если в программе используется таймер, т.к. все блокируемые системные вызовы будут прерываться по каждому тику таймера. Оба варианта хорошо описаны у http://www.ozon.ru/context/detail/id/3406745/.

Автор: xvr 17.3.2012, 10:06

Цитата(cupper @  16.3.2012,  20:52 ) Ну это по сути ненужное усложнение способа открыть пайп и записать туда что нибудь.  Ну чуть чуть отличается. Вы используете свой конец пайпа, чужой может быть эксклюзивно занят клиентом, и вы его не сможете открыть Цитата(cupper @  16.3.2012,  20:52 ) И что изменится ? Повисну в нем так же как и в select. Уточните пожалуйста, что вы имели в виду под этим, я может вас не понял. У него больше возможностей по вариантам ожидания. Возможно какая то из них может сработать например на банальное закрытие handle'а

Автор: cupper 17.3.2012, 10:37

Цитата(svlary @ 17.3.2012,  06:21) А зачем ее прерывать ? Смысл pipe как раз и заключается в том, что СЕРВЕР должен повиснуть до тех пор, пока КЛИЕНТ не положит свое сообщение в pipe. мысли глубже. А как вы сервер выключать будете ? kill -9 ? или pthread_abort ? Цитата(Fynivx @ 17.3.2012) Первый процесс создает и открывает... А второй... а второго нету, pipe открывает из ОС. Цитата(rsm @ 17.3.2012) а) создаём маску сигналов, в которой заблокировано всё; б) назначаем эту маску процессу; в) удаляем из маски какой-то сигнал, к примеру SIGUSR1; Вы выше мои изливания душевных мук на счет сигналов и синхронизации читали ? Ну по сути как не крутись есть только два способа * pselect + signal * открыть pipe для того что бы завершить поток ожидающий его. Второй явно безопаснее и проще.

Автор: rsm 17.3.2012, 16:19

Цитата(cupper @  17.3.2012,  12:37 ) Вы выше мои изливания душевных мук на счет сигналов и синхронизации читали ? Читал. Не проникся, т.к. не смог обнаружить признаков понимания работы сигналов и их воздействия на системные вызовы, потоки и процессы. Потому и посоветовал заглянуть в книжку.

Автор: cupper 17.3.2012, 18:41

Цитата(rsm @ 17.3.2012,  16:19) Цитата(cupper @  17.3.2012,  12:37 ) Вы выше мои изливания душевных мук на счет сигналов и синхронизации читали ? Читал. Не проникся, т.к. не смог обнаружить признаков понимания работы сигналов и их воздействия на системные вызовы, потоки и процессы. Потому и посоветовал заглянуть в книжку. убедили. Да я действительно не понимаю как работают сигнала, и это то из за чего я не хотел их использовать. Загляну в книжку, проникнусь.

Автор: rsm 17.3.2012, 21:17

Накатал на досуге пример (в аттаче). Для его полного понимания потребуется знать матчасть, ибо объяснять всё "от Адама" не хватит никакого форума  P.S. Извиняюсь за архив в zip - как выяснилось, родимый tgz не поддерживается для аплоада

Автор: svlary 18.3.2012, 05:28

Цитата(Fynivx @  17.3.2012,  07:04 ) куча неконтролируемых сверху процессов работают с одной областью памяти  О том, что использование COMMON переменных - весьма опасная практика, догадались еще програмисты на fortran-е 40 лет назад...  Неужели ничего в замен придумать невозможно ?! [/quote] нужно предусмотреть ситуацию, когда один из них внезапно сломается.[/quote] Специально для этого придуманы сигналы SIGPIPE и SIGCHILD. Надо просто написать обработчик соответствующих сигналов. Добавлено через 10 минут и 48 секунд Цитата(cupper @  17.3.2012,  10:37 )  А как вы сервер выключать будете ?   Для этого в ОС Linux существует стандартная методика. Например, сервер MySQL гасится командой : Код /etc/init.d/mysql stop Разработчики любых других серверов ОБЯЗАНЫ предоставить системе аналогичные средства. Цитата pipe открывает из ОС.    Это - как ?!

Автор: cupper 18.3.2012, 15:25

Цитата(svlary @ 18.3.2012,  05:28) Цитата pipe открывает из ОС.    Это - как ?! echo test > my.pipe

Автор: cupper 19.3.2012, 09:05

Цитата Ну по сути как не крутись есть только два способа * pselect + signal * открыть pipe для того что бы завершить поток ожидающий его. Второй явно безопаснее и проще. А теперь я вам скажу почему это неверно, и что я заблуждался. Открывая pipe со второй стороны что бы прервать первые мы рискуем заблокировать на этом. Если вторая сторона уже не пробует открыть pipe. Например из за какой то системной ошибки и thread прекратил работать, а мы пытаясь открыть pipe, то мы зависним в основном потоке.  И даже еще хуже, если наш тред работает, и весит на fopen. Наглядный эксперимент показал что мы спокойно в этот момент может удалить сам файл pipe физически. И тогда у нас и thread и поток вызывающий stop зависнут, и сделать уже ничего нельзя будет.  Остается один только выход pselect + signal. ... О как долго до меня доходит все это... о как долго...

Автор: svlary 19.3.2012, 12:16

Цитата(cupper @  18.3.2012,  15:25 ) echo test > my.pipe  Если я правильно понял, то Здесь изображена командная строка интерпретатора shell Пользователь запускает некую программу по имени echo в usrer-space Это может быть программа, которую написали лично Вы, а может быть из комплекта стандартных утилит Стандартный вывод этой программы перенаправлен в некий файл my.pype. Возможно - это ранее созаднный Вами именованый FIFO. Но я так и не понял, а причем тут ОПЕРАЦИОНКА, которая ОТКРЫВАЕТ именованый pipe ? Или Вы имели в виду, что где-то в теле программы echo присутствует системный вызов open(..) ? Но этот вызов есть во всех (!) прикладных программах. А ОПЕРАЦИОНКА (ядро Linux)  работает с файлами совсем по другому...  Понимание того факта, что средство pipe, ПРЕДОСТАВЛЯЕМОЕ операционной системой (ядром Linux) предназначено именно для взаимодействия двух прикладных программ (сервер и клиент) и дает ключ к пониманию того, как правильно использовать  данную возможность ОС.  Клиет и сервер всегда ВЗАИМОДЕЙСТВУЮТ. Это взаимодействие всегда выполняется по некотрому протоколу. Для открытия совместо используемого ресурса pipe используется протокол, описанный в соответствующих man ОС : man 7 pipe; man 3p pipe; man 2 pipe; Отказ от использования стандартного протокола открытия pipe ведет к необходимости изобретения разного рода финтифлюшек Добавлено через 13 минут и 49 секунд Цитата(cupper @  19.3.2012,  09:05 )  может удалить сам файл pipe физически. И тогда у нас и thread и поток вызывающий stop зависнут Не понял... Вы хотите сказать, что операция open(...), обнаружив, что файла НЕТ,  вовсе не вернет -1 и не установит errno ==  ENOENT  а просто повиснет ?!

Автор: cupper 19.3.2012, 19:59

Цитата(svlary @ 19.3.2012,  12:16) Цитата(cupper @  18.3.2012,  15:25 ) echo test > my.pipe  Если я правильно понял, то Здесь изображена командная строка интерпретатора shell Пользователь запускает некую программу по имени echo в usrer-space Это может быть программа, которую написали лично Вы, а может быть из комплекта стандартных утилит Стандартный вывод этой программы перенаправлен в некий файл my.pype. Возможно - это ранее созаднный Вами именованый FIFO. Но я так и не понял, а причем тут ОПЕРАЦИОНКА, которая ОТКРЫВАЕТ именованый pipe ? Или Вы имели в виду, что где-то в теле программы echo присутствует системный вызов open(..) ? Но этот вызов есть во всех (!) прикладных программах. А ОПЕРАЦИОНКА (ядро Linux)  работает с файлами совсем по другому...  Понимание того факта, что средство pipe, ПРЕДОСТАВЛЯЕМОЕ операционной системой (ядром Linux) предназначено именно для взаимодействия двух прикладных программ (сервер и клиент) и дает ключ к пониманию того, как правильно использовать  данную возможность ОС.  Клиет и сервер всегда ВЗАИМОДЕЙСТВУЮТ. Это взаимодействие всегда выполняется по некотрому протоколу. Для открытия совместо используемого ресурса pipe используется протокол, описанный в соответствующих man ОС : man 7 pipe; man 3p pipe; man 2 pipe; Отказ от использования стандартного протокола открытия pipe ведет к необходимости изобретения разного рода финтифлюшек Добавлено @ 12:29 Цитата(cupper @  19.3.2012,  09:05 )  может удалить сам файл pipe физически. И тогда у нас и thread и поток вызывающий stop зависнут простите но вы кэп  про всякое там правильное взаимодействие с pipe комментировать не буду. Цитата(svlary @ 19.3.2012,  12:16) Не понял... Вы хотите сказать, что операция open(...), обнаружив, что файла НЕТ,  вовсе не вернет -1 и не установит errno ==  ENOENT  а просто повиснет ?! Уху  Я проверял только для случая если open уже вызвали и заблокировались на ней. Если мы вызовем open просто на несуществующем файле, то тут поведение будет стандартное для этой функции.

Автор: cupper 19.3.2012, 23:26

Вкуриваю тему сигналов. Споткнулся о sigprocmask и pthread_sigmask. Ну вернее в начале я всттетил кучу примеров именно с sigprocmask. Далее смлучайным образов нашел pthread_sigmask, еще немного полистав интернет таки понял в чем разница. Но не нашел аналогичного для sigaction... ну вот не хочу я обработчик ставить для всех, хочу только для текущего треда... что делать ?

Автор: svlary 20.3.2012, 07:01

Цитата(cupper @  19.3.2012,  19:59 ) простите но вы кэп  Может быть и так...   Но : Мои очевидные программы работают (я написал с десяток систем клиент/сервер на pipe); Ваши не очевидные - не рабатоают. Не смею больше Вам мешать...

Автор: rsm 20.3.2012, 17:25

Цитата(cupper @  20.3.2012,  01:26 ) не хочу я обработчик ставить для всех, хочу только для текущего треда Сигналы отправляются процессу, а не потоку. Можно выделить отдельный поток, который будет обрабатывать очередь поступающих сигналов - однако это не изменит того, что они приходят процессу. Цитата(cupper @  19.3.2012,  11:05 ) Открывая pipe со второй стороны что бы прервать первые мы рискуем заблокировать на этом От этого помогает мультиплексирование (даже если оно как таковое не требуется), т.к. переданные дескрипторы проверяются на готовность к чтению. Если они не готовы, можно выйти либо по таймауту, либо по сигналу. Предлагаю всё-таки потыкать в приаттаченый выше пример.

Автор: cupper 21.3.2012, 10:21

Цитата(rsm @ 20.3.2012,  17:25) Сигналы отправляются процессу, а не потоку. Цитата Name pthread_kill - send a signal to a thread Synopsis #include <signal.h>int pthread_kill(pthread_t thread, int sig); Compile and link with -pthread. Description  The pthread_kill() function sends the signal sig to thread, another thread in the same process as the caller. The signal is asynchronously directed to thread. If sig is 0, then no signal is sent, but error checking is still performed; this can be used to check for the existence of a thread ID. я как то не правильно понимаю либо вас либо описание выше ? Цитата(rsm @ 20.3.2012,  17:25) Предлагаю всё-таки потыкать в приаттаченый выше пример.  Забыл :( Посмотрел. Удивлен. poll умеет реально определять были ли положены в pipe данные, когда select меня просто по бороде пускал и пролетал мимо. Тогда если скрестить pthread_kill и ppoll то вроде бы получиться то что надо. Спасибо.

Автор: rsm 21.3.2012, 16:07

Цитата(cupper @  21.3.2012,  12:21 ) я как то не правильно понимаю либо вас либо описание выше? Есть один нюанс в терминологии: в GNU/Linux потоки - это по факту процессы

Автор: cupper 21.3.2012, 23:08

Цитата(rsm @ 21.3.2012,  16:07) Цитата(cupper @  21.3.2012,  12:21 ) я как то не правильно понимаю либо вас либо описание выше? Есть один нюанс в терминологии: в GNU/Linux потоки - это по факту процессы  ну я так и знал что вы это скажите  Так же по сути мы можем слать сигналы в тред (так как он по сути как процесс  ) И еще, у меня вопрос по вашему примеру Код     /* устанавливаем процессу маску сигналов, блокируя приём всех сигналов */     if (sigprocmask(SIG_SETMASK, signals_mask, NULL) == -1)     {         perror("sigprocmask()");         return 2;     } Где опечатка ? В комментарии или в SIG_SETMASK ? По сути этот код ничего не делает. И тут я подхожу к своему следующему вопросу.  Я понимаю что делает sigaction и я понимаю что делает sigprocmask. И так, первая функция регистрирует НАШ обработчик для заданного сигнала.  Вторая функция напротив блокирует получение процессом сигнала. Далее функции типа ppoll, pselect снимают блокировку сигналов которые вы укажите им в параметрах. Но, они гарантируют, что сразу после получения сего сигнала, его настройки будут возвращены в то состояние, которые было перед вызовом. В нашем случае состояние БЛОКИРОВАНИЯ сигнала. Таким образом, нет смысла использовать их вместе.  Но, стоит понять какую из них НУЖНО использовать.  Итак, если мы используем sigprocmask то мы заблокируем сигнал, далее вызовем ppoll. Но как мы выйдя из ppoll сможем определить почему мы вышли ? из за сигнала или из за того что поступили данные ? Спецификаци ppoll говорит нам что errno будет установлено в EINTR если мы вышли из за сигнала. Гип гип ура. Далее, если мы используем sigaction, то по выходу из ppoll мы собстно можем узнать это по какой то внешней переменной которую мы установили в обработчике сигнала. И опять таки гип гип ура  У вас в примере, реализовано сразу оба способа (что ни есть гуд)  но по сути преобладает sigaction + ppoll как раз и за того с чего я начал сей  пост. Если я где то ошибся поправьте меня.  -- истина где то рядом

Автор: rsm 22.3.2012, 03:20

Цитата(cupper @  22.3.2012,  01:08 ) по сути мы можем слать сигналы в тред (так как он по сути как процесс) Разные термины возникли не зря - не смотря на то, что потоки по факту процессы, сигналы в потоках и процессах обрабатываются по-разному. Не стоит об этом забывать, иначе однажды можно наступить на неприятные грабли  Цитата(cupper @  22.3.2012,  01:08 ) Если я где то ошибся поправьте меня Я не понял, в чём состоит вопрос  Подразумевалось, что приход сигнала можно выявить по коду EINTR и тогда можно не устанавливать свой обработчик сигналов? В таком случае вынужден огорчить - ppoll запросто может вернуть EINTR, даже если никакого сигнала не было.

Автор: cupper 22.3.2012, 09:04

Цитата(rsm @  22.3.2012,  03:20 ) Разные термины возникли не зря - не смотря на то, что потоки по факту процессы, сигналы в потоках и процессах обрабатываются по-разному. Не стоит об этом забывать, иначе однажды можно наступить на неприятные грабли  пример граблей ?  Цитата(rsm @  22.3.2012,  03:20 ) Я не понял, в чём состоит вопрос первый на счет  Код    /* устанавливаем процессу маску сигналов, блокируя приём всех сигналов */     if (sigprocmask(SIG_SETMASK, signals_mask, NULL) == -1)     {         perror("sigprocmask()");         return 2;     } Сам вопрос в посте выше. Цитата(rsm @  22.3.2012,  03:20 )  В таком случае вынужден огорчить - ppoll запросто может вернуть EINTR, даже если никакого сигнала не было.  пример ? Ну или хотя бы где это описано. На счет sigprocmask и sigaction пока молчу, нужно еще поэксперементировать.

Автор: rsm 22.3.2012, 16:26

Цитата(cupper @  22.3.2012,  11:04 ) пример граблей ? У каждого потока своя маска сигналов, однако диспозиция сигналов - одна на всех. Если один поток установил диспозицию сигнала на игнорирование, а другой поток - на обработчик, то по приходу сигнала будет использована диспозиция, установленная последней. Как следствие - грабли, которые будет сложно отловить, т.к. визуально все выглядит корректно. Цитата(cupper @  22.3.2012,  11:04 ) первый на счет sigprocmask Всё равно не понимаю, в чём вопрос?  Смущает SIG_SETMASK? Это означает, что процессу следует установить новую маску сигналов, в точности равную заданной, игнорируя значение текущей маски. Цитата(cupper @  22.3.2012,  11:04 ) пример ? Ну или хотя бы где это описано У http://www.ozon.ru/context/detail/id/3406745/ этому посвящена целая глава 10.5, страница 373.

Автор: cupper 22.3.2012, 18:33

Цитата(rsm @  22.3.2012,  16:26 )  однако диспозиция сигналов чего ? можете пояснить ? Цитата(rsm @  22.3.2012,  16:26 )  Смущает SIG_SETMASK? Это означает, что процессу следует установить новую маску сигналов, в точности равную заданной, игнорируя значение текущей маски. кажется с совсем запутался. Я точно помню что я где то читал что сей параметр (или может просто похожий) заставляет сбросить state для заданных сигналов в дефолтное значение. Цитата(rsm @  22.3.2012,  16:26 ) Цитата(cupper @  22.3.2012,  11:04 ) пример ? Ну или хотя бы где это описано У Стивенса этому посвящена целая глава 10.5, страница 373.  эх, будем вкуривать. Черт побери эти линуксы :(

Автор: rsm 22.3.2012, 20:03

Цитата(cupper @  22.3.2012,  20:33 ) чего ? можете пояснить ? "Диспозиция" можно без потери смысла заменить на "http://ru.wikipedia.org/wiki/Callback_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)" - не знаю, откуда переводчик книги Стивенса выкопал это необычайное слово (диспозиция)  Для лучшего понимания рассмотрим применение простой, но устаревшей функции signal: Код /*     установить диспозицию сигнала USR1 на игнорирование,     т.е. сигнал USR1 будет игнорироваться процессом */ signal(SIGUSR1, SIG_IGN); /*     установить диспозицию сигнала USR1 на действие по-умолчанию,     т.е. при получении процессом сигнала USR1 будет выполнено     действие по-умолчанию (завершение процесса) */ signal(SIGUSR1, SIG_DEF); /*     созданный разработчиком callback для обработки сигналов */ static void on_signal(int signo) {     /* всякое */ } /*    установить диспозицию сигнала USR1 на callback `on_signal()',    т.е. по приходу сигнала USR1 вызывать созданный разработчиком    callback `on_signal()' */ signal(SIGUSR1, &on_signal); Пример, полагаю, понятен? А теперь представим, что будет, если каждый вызов функции signal выполняется в отдельном потоке. Какая именно диспозиция будет назначена для сигнала USR1: игнорирование, действие по-умолчанию или callback? Если не синхронизировать потоки принудительно, получится игра в рулетку - нельзя предсказать, что будет диспозицией сигнала, т.к. достоверно неизвестно, какой поток выполнит вызов функции signal последним. Это и есть те грабли, про которые я упоминал выше, говоря об особенностях обработки сигналов в потоках. P.S. В современных программах никогда не следует использовать функцию signal, ей на смену пришла функция sigaction. Цитата(cupper @  22.3.2012,  20:33 ) я где то читал что сей параметр (или может просто похожий) заставляет сбросить state для заданных сигналов в дефолтное значение У каждого процесса есть его текущая маска сигналов. Функция sigprocmask, принимая как аргумент новую маску сигналов, позволяет выполнить следующие действия: а) SIG_BLOCK - добавить к текущей маске сигналы, заданные в новой маске; б) SIG_SETMASK - установить текущую маску полностью идентичной новой маске; в) SIG_UNBLOCK - убрать из текущей маски сигналы, заданные в новой маске; Цитата(cupper @  22.3.2012,  20:33 ) Черт побери эти линуксы К чему себя заставлять, есть же http://lurkmore.to/Windows?

Автор: cupper 22.3.2012, 21:58

Цитата(rsm @  22.3.2012,  20:03 )  А теперь представим, что будет, если каждый вызов функции signal выполняется в отдельном потоке. А ну это то понятно было изначально. Речи об использовании этой функции не было. Цитата(rsm @  22.3.2012,  20:03 ) У каждого процесса есть его текущая маска сигналов. Функция sigprocmask, принимая как аргумент новую маску сигналов, позволяет выполнить следующие действия: а) SIG_BLOCK - добавить к текущей маске сигналы, заданные в новой маске; б) SIG_SETMASK - установить текущую маску полностью идентичной новой маске; в) SIG_UNBLOCK - убрать из текущей маски сигналы, заданные в новой маске; Добрался до домашнего компа, и таки понял где я "промахнулся". Именно в нонимании это функции. Вернее в том что SIG_BLOCK/SIG_UNBLOCK это не указание на то что блокировать или не блокировать сигналы, как в сигнал в signal - SIG_IGN. Я не знал что у процесс изначально есть маска сигналов которая именно заблокирована. Я думал что sigprocmask как раз позволяет сделать блокировку этих сигналов. А привело меня к этому наверно неправильное толкование вот этого описания Цитата http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.zos.r11.bpxbd00/select.htm Typically, sigprocmask(SIG_BLOCK, ..., ...) is used to block signals during a critical section of code. At the end of the critical section of code, sigprocmask(SIG_SETMASK, ..., ...) is used to restore the mask to the previous value returned by sigprocmask(SIG_BLOCK, ..., ...). option Indicates the way in which the existing set of blocked signals should be changed. The following are the possible values for option, defined in the signal.h header file: SIG_BLOCK Indicates that the set of signals given by new_set should be blocked, in addition to the set currently being blocked. SIG_UNBLOCK Indicates that the set of signals given by new_set should not be blocked. These signals are removed from the current set of signals being blocked. SIG_SETMASK Indicates that the set of signals given by new_set should replace the old set of signals being blocked. Еще раз спасибо  Но это еще не все, щас подготовлю пример для последнего наверно вопроса. На счет sigaction в тредах. PS. sigaction работает на весь процесс и на каждую нить. А основное мое не поние было в том что функции sigwait и ppoll в обработке сигналов различаются как земля и небо. sigwait не позволяет выполниться обработчику (из sigaction). ppoll напротив позволяет.  Гип гип ура, мать его. Наконец таки я доделаю свои долбаные пайпы. Прибольшое спасибо вам rsm, мне б к вам в ученики

Автор: rsm 23.3.2012, 04:53

Цитата(cupper @  22.3.2012,  23:58 ) Прибольшое спасибо вам rsm, мне б к вам в ученики Форум решает

Автор: cupper 25.3.2012, 19:15

Цитата(cupper @  15.3.2012,  22:33 ) Второй вариант, используем неблокирующий режим Код mkfifo(FIFO_FILE, 0666) handle_ = open(FIFO_FILE, O_RDWR | O_NONBLOCK); int flags; if ((flags = fcntl(handle_, F_GETFL, 0)) < 0) printf("ERROR: fcntl get\n"); flags &= ~O_NONBLOCK; if (fcntl(handle_, F_SETFL, flags) < 0) printf("ERROR: fcntl set\n"); fd_set rfds; FD_ZERO(&rfds); FD_SET(handle_, &rfds); if(select(handle_ + 1, NULL, &rfds, &rfds, NULL) == -1) Пояснение 1: после того как мы "открыли" pipe переводим его в блокирующий режим иначе каждая наша операция будет сразу возвращаться управление. Пояснение 2: используем select, но мы не можем использовать его для операции read так как она возвращает 0 на еще не открытом pipe, поэтому открываем pipe в оба режима, и блокируемся на операции write. собрав силы в кулак я вернулся к старому коду. Увидев в примере rsm использование ppoll (когда происходило блокирование при чтении в O_NONBLOCK pipe) я решил что это просто такая хорошая функция которая лучше чем pselect. Решил в этом убедится, достал свой код с select, поменял на  Код     mkfifo(PIPE, 0666);     int hdl = open(PIPE, O_RDONLY | O_NONBLOCK);         fd_set fd;     FD_ZERO(&fd);     FD_SET(hdl, &fd);     std::cout << "after select\n";     select(hdl + 1, &fd, NULL, NULL, 0);     std::cout << "before select\n"; и тут мне стало совсем дурно, потому что операция select заблокировалась на чтении. Но это невозможно !!! Ведь просто операция чтения вставленная строчкой выше select пролетает и возвращает 0. Как ???? Как он блокируется ??? Я рву волосы на голове пытаясь вспомнить как я писал код (а я его писал, и не в одной вариации) что у мня select не блокировался, не блокировался даже на запись если я открывал pipe как O_RDWR | O_NONBLOCK. Но увы, код утерян, и я не могу получить пример в подтверждение своих слов в начале поста. Я ей богу не понимаю почему теперь select блокируется.

Автор: xvr 25.3.2012, 22:53

Цитата(cupper @  25.3.2012,  19:15 ) Ведь просто операция чтения вставленная строчкой выше select пролетает и возвращает 0. Как ???? Это нормально. Ваша 'операция чтения строчкой выше' вылетела с нулем потому что был выставлен флаг O_NONBLOCK, который означает - 'операции ввода/вывода никогда не блокировать'. Но на select это не распространяется (его на то и сделали, что бы можно было ждать реального поступления данных)

Автор: cupper 26.3.2012, 08:48

Цитата(xvr @  25.3.2012,  22:53 ) Это нормально. Ваша 'операция чтения строчкой выше' вылетела с нулем потому что был выставлен флаг O_NONBLOCK, который означает - 'операции ввода/вывода никогда не блокировать'. Но на select это не распространяется (его на то и сделали, что бы можно было ждать реального поступления данных) да ну ладно вам Цитата select() and pselect() allow a program to monitor multiple file descriptors, waiting until one or more of the file descriptors become "ready" for some class of I/O operation (e.g., input possible). A file descriptor is considered ready if it is possible to perform the corresponding I/O operation (e.g., read(2)) without blocking.

Автор: xvr 26.3.2012, 13:03

Цитата(cupper @  26.3.2012,  08:48 ) A file descriptor is considered ready if it is possible to perform the corresponding I/O operation (e.g., read(2)) without blocking. Но это не значит, что он обратит внимание на флаг O_NONBLOCK. И он не обращает    Так что тут надо читать так :  Цитата A file descriptor is considered ready if it is possible to perform the corresponding I/O operation in blocking mode (e.g., read(2)) without blocking.

Автор: cupper 26.3.2012, 14:58

Цитата(xvr @  26.3.2012,  13:03 ) Но это не значит, что он обратит внимание на флаг O_NONBLOCK. И он не обращает хе  тут даже и не поспоришь... в мане собстно не сказано ни первое ни второе. Странно, ведь про таймер они там во все горло кричат что это опасные грабли.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)