Граждане, такой вопросик к гуру: у меня есть два работающих процесса, открыта труба между ними (для передачи данных), писатель пишет в трубу, читатель спит, одно не пойму: как мне сообщить читателю, чтобы он проснулся и прочитал данные? В инете встретил инфу о механизме сигналов, семафоров и т.п. подскажите, что лучше тут использовать, и как? И если можно, какую-нить литературу. Спасибо

чем блокирующий read или select не устраивает ?

Я не могу понять как пробудить процесс (или сообщить ему, что есть данные) , а потом он конечно поюзает read, что бы прочитать.

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

Около темы: советую библию "UNIX. Профессиональное программирование", 2-е издание

ищи "linux shared memory"

т.е. трубы - это уже все, старье?

с каждым объектом межпроцессного взаимодействия связан файловый дескриптор для организации доступа к объекту и управления этим объектом.

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

to Tag: спасибо! это похоже как раз то, что мне и нужно было!

зы читаю сейчас про shared memory http://www.kstu.kz/~tolik/info/alp/alp-ch05-ipc.pdf
очень неплохая штука похоже, будет время освою обязательно...

есть еще один маленький вопросик по поводу select. я сделал небольшой тестик и заметил, что select активируется как только в трубу записан первый байт, а не все сооббщение. это нормально?

Типичный пример так называемой каши в голове.

1) А. Робачевский "Операционная система Unix".
2) У. Стивенс "Взаимодействие процессов".
3) Э. Реймонд "Искусство программирования Unix".

Всё существует в электронном виде (если не найти -- выдам). Но лучше купить в бумажном и поставить на полку.

Как сообщить чтоб проснулся... А кто его, спрашивается, заснул. read(2)? Ну так и проснётся, как только, так
сразу. Если надо несколько событий отслеживать -- select().

Смешивать сигналы и семафоры в кучу не надо. В Unix одновременно несколько механизмов по наследству досталось.
Перечислю разные механизмы:

0) Асинхронные сигналы (man 7 signal). Это что-то вроде прерываний в микроконтроллере. Их дцать
штук и возникают они по разным поводам, или их может кто-то послать, почти все из них можно
перехватить. Ключевое слово -- асинхронные, т.е. возникают когда придётся.

1) Собственно pipe и fifo. Это специальные типы файлов (man 7 pipe), могут быть именованные, могут
быть безымянные (это которые создаются когда делается, например sort | ls -- man 2 pipe). Принцип
работы понятен -- при открытии образуется два файл-дескриптора, один для чтения другой для записи.
В один пишут, из второго появляется... Дескриптор может быть передан в другой процесс (посредством
fork(), например, собственно для того pipe и нужны).

2) Виртуальные терминалы (man 7 pty). Используются примерно как pipe, но в ситуации когда ввод и вывод
программы надо направить в другую программу, например. Разница с pipe заключается в том, что во-первых
они именованные, во-вторых файла два: один управляющий, другой ведомый. Управляющей используется
программой симулирующей терминал, ведомый используется программой использующей терминал и с её
точки зрения от терминала не отличается. Данные через оба файла в любом направлении, как и в случае
реального терминала, передаются во-первых, во-вторых появляющиеся на входе управляющего файла
данные подвергаются специальной интерпретации со стороны ядра (это как бы обработка клавиатуры --
прочтение раздела "Low level terminal inteface" в info libc может поможет пониманию -- там есть разные
настраиваемые режимы по обработке вводимого потока данных). Пример использования виртуального
терминала -- работа в telnet (ssh) -- на удалённом конце ведомый файл подключается к shell'у, а управляющий
к демону telnetd (sshd) которые работают уже с сетью.

3) Локальные unix-сокеты (где сокет -- специальный тип файла)
4) и IP сокеты (где сокет -- соединение на адрес и порт -- man 7 socket)

Про IP сокеты и так все знают, они же и в windows есть, только там всё (в windows) извращено до неузнаваемости.
Локальные сокеты по принципу работы ничем не отличаются, почти, кроме того, что для установления соединения
нужены не пара адрес и порт (ну и плюс используемый протокол, определяемый сокетом), а специальный файл
в файловой системе, который собственно сокет и идентифицирует. Ну ещё с помощью socketpair(2), по аналогии
с pipe(2), может быть создана анонимная пара сокетов. В общем отличие от pipe -- двунаправленность и несколько
разная работа в плане read/write и сигналов...

5) Так называемая SysV IPC, содержит семафоры, очереди сообщений и разделяемую между процессами память.
НЕ НАДО ПУТАТЬ С АНАЛОГИЧНЫМИ МЕХАНИЗМАМИ В МНОГОПОТОЧНЫХ ПРИЛОЖЕНИЯХ (на libpthreads).
Это для сообщения между процессами. Устаревший и часто неактуальный механизм, о котором можно почитать
в man 7 svipc. Вместо сообщений вполне можно использовать менее проблемные сокеты, в качестве разделяемой
памяти -- mmap(2) файла, в качестве семафоров -- блокировки файлов, например. И другие механизмы есть, вроде
posix-ipc.

6) POSIX-ipc: тоже очереди сообщений (man mq_overview), семафоры (man sem_overview) и разделяемую память
тоже (man shm_open).

7) Обыкновенные объекты файловой системы могут иметь блокировки (примерно как в виндовс),
разумеется для атомарного доступа. man fcntl flock lockf...

8) имеются и другие, более ОС-специфичные (например, только для linux) методы...
И опять же не надо путать с многопоточными приложениями. А если интересует аналог
WaitForBlablabla() из мира windows, то аналогом случит select() (ну и что, что вместо
"евента" или чего-то ещё используется обыкновенный файл типа pipe...)

Да, маны даны специфичные для Linux и в BSD или Solaris их может не быть (там другие есть).

Напоминаю, существует телеконференция fido7.ru.unix.prog (в фидонете, доступ пожно получить,
посмотрите как, на http://ddt.demos.su/) где могут квалифицированно на русском языке прояснить
ваши вопросы.

спасибо за столь объемные разъяснения, думаю они пригодятся не только мне...

Похоже в моем случае можно обойтись без select. Судя по ману, (блокирующий по умолчанию) read засыпает при попытке читать данные из fifo до тех пор пока они там не появятся...