echo test > my.pipe

А теперь я вам скажу почему это неверно, и что я заблуждался. Открывая pipe со второй стороны что бы прервать первые мы рискуем заблокировать на этом. Если вторая сторона уже не пробует открыть pipe. Например из за какой то системной ошибки и thread прекратил работать, а мы пытаясь открыть pipe, то мы зависним в основном потоке. 

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

Остается один только выход pselect + signal.

... О как долго до меня доходит все это... о как долго...

Если я правильно понял, то

• Здесь изображена командная строка интерпретатора 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 секунд


Не понял... Вы хотите сказать, что операция open(...), обнаружив, что файла НЕТ,  вовсе не вернет -1 и не установит errno ==  ENOENT  а просто повиснет ?!

простите но вы кэп 

про всякое там правильное взаимодействие с pipe комментировать не буду.


Уху  Я проверял только для случая если open уже вызвали и заблокировались на ней. Если мы вызовем open просто на несуществующем файле, то тут поведение будет стандартное для этой функции.


Это сообщение отредактировал(а) cupper - 19.3.2012, 20:03

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

Может быть и так...   Но :

• Мои очевидные программы работают (я написал с десяток систем клиент/сервер на pipe);
• Ваши не очевидные - не рабатоают.

Не смею больше Вам мешать... 

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


От этого помогает мультиплексирование (даже если оно как таковое не требуется), т.к. переданные дескрипторы проверяются на готовность к чтению. Если они не готовы, можно выйти либо по таймауту, либо по сигналу. Предлагаю всё-таки потыкать в приаттаченый выше пример.

я как то не правильно понимаю либо вас либо описание выше ?


Забыл :( Посмотрел. Удивлен. poll умеет реально определять были ли положены в pipe данные, когда select меня просто по бороде пускал и пролетал мимо. Тогда если скрестить pthread_kill и ppoll то вроде бы получиться то что надо.

Спасибо.


Это сообщение отредактировал(а) cupper - 21.3.2012, 10:24

Есть один нюанс в терминологии: в GNU/Linux потоки - это по факту процессы 

ну я так и знал что вы это скажите  Так же по сути мы можем слать сигналы в тред (так как он по сути как процесс  )

И еще, у меня вопрос по вашему примеру


Где опечатка ? В комментарии или в SIG_SETMASK ?

По сути этот код ничего не делает. И тут я подхожу к своему следующему вопросу. 
Я понимаю что делает sigaction и я понимаю что делает sigprocmask.

И так, первая функция регистрирует НАШ обработчик для заданного сигнала. 
Вторая функция напротив блокирует получение процессом сигнала.

Далее функции типа ppoll, pselect снимают блокировку сигналов которые вы укажите им в параметрах. Но, они гарантируют, что сразу после получения сего сигнала, его настройки будут возвращены в то состояние, которые было перед вызовом. В нашем случае состояние БЛОКИРОВАНИЯ сигнала.

Таким образом, нет смысла использовать их вместе. 
Но, стоит понять какую из них НУЖНО использовать. 

Итак, если мы используем sigprocmask то мы заблокируем сигнал, далее вызовем ppoll. Но как мы выйдя из ppoll сможем определить почему мы вышли ? из за сигнала или из за того что поступили данные ? Спецификаци ppoll говорит нам что errno будет установлено в EINTR если мы вышли из за сигнала. Гип гип ура.

Далее, если мы используем sigaction, то по выходу из ppoll мы собстно можем узнать это по какой то внешней переменной которую мы установили в обработчике сигнала. И опять таки гип гип ура 

У вас в примере, реализовано сразу оба способа (что ни есть гуд)  но по сути преобладает sigaction + ppoll как раз и за того с чего я начал сей  пост.

Если я где то ошибся поправьте меня. 

--
истина где то рядом

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


Я не понял, в чём состоит вопрос  Подразумевалось, что приход сигнала можно выявить по коду EINTR и тогда можно не устанавливать свой обработчик сигналов? В таком случае вынужден огорчить - ppoll запросто может вернуть EINTR, даже если никакого сигнала не было.

пример граблей ? 


первый на счет 

Сам вопрос в посте выше.


пример ? Ну или хотя бы где это описано.


На счет sigprocmask и sigaction пока молчу, нужно еще поэксперементировать.

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


Всё равно не понимаю, в чём вопрос?  Смущает SIG_SETMASK? Это означает, что процессу следует установить новую маску сигналов, в точности равную заданной, игнорируя значение текущей маски.


У Стивенса этому посвящена целая глава 10.5, страница 373.

чего ? можете пояснить ?



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


эх, будем вкуривать. Черт побери эти линуксы :(

Это сообщение отредактировал(а) cupper - 22.3.2012, 18:44

"Диспозиция" можно без потери смысла заменить на "callback" - не знаю, откуда переводчик книги Стивенса выкопал это необычайное слово (диспозиция)  Для лучшего понимания рассмотрим применение простой, но устаревшей функции signal:


Пример, полагаю, понятен? А теперь представим, что будет, если каждый вызов функции signal выполняется в отдельном потоке. Какая именно диспозиция будет назначена для сигнала USR1: игнорирование, действие по-умолчанию или callback? Если не синхронизировать потоки принудительно, получится игра в рулетку - нельзя предсказать, что будет диспозицией сигнала, т.к. достоверно неизвестно, какой поток выполнит вызов функции signal последним. Это и есть те грабли, про которые я упоминал выше, говоря об особенностях обработки сигналов в потоках.

P.S. В современных программах никогда не следует использовать функцию signal, ей на смену пришла функция sigaction.


У каждого процесса есть его текущая маска сигналов. Функция sigprocmask, принимая как аргумент новую маску сигналов, позволяет выполнить следующие действия:
а) SIG_BLOCK - добавить к текущей маске сигналы, заданные в новой маске;
б) SIG_SETMASK - установить текущую маску полностью идентичной новой маске;
в) SIG_UNBLOCK - убрать из текущей маски сигналы, заданные в новой маске;


К чему себя заставлять, есть же уютненькая?