Пытаюсь реализовать корректное завершение потока заблокированного на операции с pipe'ом.

Первый вариант работа в лоб

заблокируется на операции open до тех пор пока другой процесс не откроет pipe на запись. Прервать эту операцию на вряд ли получится. Я не нашел способа.

Второй вариант, используем неблокирующий режим

Пояснение 1: после того как мы "открыли" pipe переводим его в блокирующий режим иначе каждая наша операция будет сразу возвращаться управление.
Пояснение 2: используем select, но мы не можем использовать его для операции read так как она возвращает 0 на еще не открытом pipe, поэтому открываем pipe в оба режима, и блокируемся на операции write.

Я было надеялся что операция write прервется если мы сделаем close(), но она не прерывается. Так же не появляется исключительная ситуация (для которой я попробовал установить 4 параметр select).

Долго и усердно пытался найти как прервать select. Не нашел. 
Вариант использования pselect плохой, так как я не могу послать сигнал в поток он шлется в процесс.

Единственным вариантом пока вижу прерывать поток открытием pipe со второй стороны, ну и например записью туда какого нибудь значение по которому прерываемый поток узнает что это команда exit. Но и этот вариант мне не кажется хорошим. 

Излазил весь интернет, все что нашел сведено в коде выше.

PS. хммм, обнаружил такую функцию pthread_kill... неужели в лине можно послать сигнал конкретному потоку ?

Это сообщение отредактировал(а) cupper - 15.3.2012, 23:26

Открыть еще один pipe (анонимный) и подать его 2м handle'ом в select. Ну и записать в него что нибудь, что бы прервать select.
Еще можно использовать eventfd вместо 2го пайпа (если у вас ядро >  2.6.22)


Попробуйте poll или epoll

Ну это по сути ненужное усложнение способа открыть пайп и записать туда что нибудь. 


И что изменится ? Повисну в нем так же как и в select. Уточните пожалуйста, что вы имели в виду под этим, я может вас не понял.


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

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

Потоки уже стандартизированы в C++...

в винде я так и сделал, там есть Event и есть WaitForMultipleObject.
В linux аналога нету. Есть select который умеет проверять что следующая операция (чтения, записи) не будет блокирующая. Есть pselect который еще умеет ждать сигнал (но сигналы то шлются все тредам, хотя есть pthread_kill но его работа для меня пока не очень ясна, да и сигнал это не средство синхронизации).

Использовать TimeOut вообще плохая затея. 

Но я не понял как вы предлагаете скрестить condition_variable и блокирующую open или write ? Это как раз то что нужно, вот только я не знаю возможно ли такое 

Блокирующий - не знаю. А с неблокирующим возможно. По крайней мере, я представляю примерно так:

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

А второй, опять же, открывает очередь, и посылает первому сообщение об открытии через notify.
Как-то так.

notify_one посылает сигнал одному процессу, notify_all - всем ожидающим.

Вообще можно организовать очередь любого типа нативными средствами. По крайней мере, я бы так сделал. И никакой привязки к операционке не будет. Хм... Или у Вас привязка к C а не к C++?


А можете описать задачу взаимодействия процессов в целом? Может, что проще придумается и без хэдеров windows и pthreads.

    А зачем ее прерывать ? Смысл pipe как раз и заключается в том, что СЕРВЕР должен повиснуть до тех пор, пока КЛИЕНТ не положит 
свое сообщение в pipe.  Главная мысль : pipe должны использовать два (!) процесса. И один из них должен постоянно 
висеть на чтении. Проще говоря - ждать прихода сообщения. И это абсолютно  нормальная логика клиент/серверных технологий.
Зачем ее ломать изобретая деревянные велосипеды на треугольных колесах - я не понимаю.

   Если же Вы хотите что бы и клиент и сервер запускались из одного исполняемого модуля, то можно сделать так :




Для ознакомления с классикой программирования под Unix/Linux рекомендую хотя бы : Марк Дж Рочкинд. "Программирование для UNIX". 

Бывают такие ситуации. Вот у меня, например, сейчас в одном проекте наблюдается следующая картина:  куча неконтролируемых сверху процессов работают с одной областью памяти, причем никто из них не знает, кто когда завершится или прервется.
Нетрудно представить ситуацию, когда пара таких процессов, вместо использования общей памяти, общаются между собой пайпами. И тогда нужно предусмотреть ситуацию, когда один из них внезапно сломается.

Но я, честно говоря, не могу представить ситуацию, где их использование выгоднее)

Добавлено через 3 минуты и 31 секунду
Даже для двух совершенно разных модулей, написанных на разных языках, можно сообразить шаред-мемори через dll'ку)

Как один из самых элементарных вариантов:
а) создаём маску сигналов, в которой заблокировано всё;
б) назначаем эту маску процессу;
в) удаляем из маски какой-то сигнал, к примеру SIGUSR1;
г) висим на pselect;
д) когда надо, сами себе оправляем заранее определённый сигнал (SIGUSR1);
е) pselect завершается по прерванному системному вызову;
Вариант другой, более годный: вынести обработку сигналов в отдельный поток. Делать такое необходимо, если в программе используется таймер, т.к. все блокируемые системные вызовы будут прерываться по каждому тику таймера.
Оба варианта хорошо описаны у Стивенса.

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


У него больше возможностей по вариантам ожидания. Возможно какая то из них может сработать например на банальное закрытие handle'а

мысли глубже. А как вы сервер выключать будете ? kill -9 ? или pthread_abort ?


а второго нету, pipe открывает из ОС.



Вы выше мои изливания душевных мук на счет сигналов и синхронизации читали ?

Ну по сути как не крутись есть только два способа
* pselect + signal
* открыть pipe для того что бы завершить поток ожидающий его.

Второй явно безопаснее и проще.

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

Читал. Не проникся, т.к. не смог обнаружить признаков понимания работы сигналов и их воздействия на системные вызовы, потоки и процессы. Потому и посоветовал заглянуть в книжку.

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

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

Присоединённый файл ( Кол-во скачиваний: 6 )
 pipe_example.zip 4,47 Kb

 О том, что использование COMMON переменных - весьма опасная практика, догадались еще програмисты на fortran-е 40 лет назад...  Неужели ничего в замен придумать невозможно ?!

[/quote]
нужно предусмотреть ситуацию, когда один из них внезапно сломается.[/quote]

Специально для этого придуманы сигналы SIGPIPE и SIGCHILD. Надо просто написать обработчик соответствующих сигналов.

Добавлено через 10 минут и 48 секунд

  Для этого в ОС Linux существует стандартная методика. Например, сервер MySQL гасится командой :



Разработчики любых других серверов ОБЯЗАНЫ предоставить системе аналогичные средства.


   Это - как ?!