Межпроцессное взаимодействие на одной машине, сигнале или сокете, как решить?

#c #sockets #ipc #signals

#c #сокеты #ipc #сигналы

Вопрос:

Мне кажется, что для этой работы можно использовать оба signal и socket ,

как вы решаете, какой из них использовать на самом деле?

1. Можете ли вы подробнее рассказать об информации, которая будет передаваться между двумя процессами? Существует множество методов межпроцессного взаимодействия.

2. Использование сигналов для IPC похоже на выбор pidgeons для почты. Есть более удобные альтернативы.

3. Избегайте сигналов, если это возможно; они очень примитивны и ограничены в том, что они могут делать.

Ответ №1:

Использование сигналов для IPC в некотором роде неудобно и примитивно. Вам действительно следует выбирать между сокетами Unix (не TCP!) и каналами.

Каналы, как правило, легче программировать, поскольку они гарантируют, что один файл, write меньший PIPE_BUF размера, является атомарным. Однако у них есть свои ограничения. Например, когда запись выполняется быстрее, чем считывание, запись начинает блокироваться, когда буфер канала заполняется. Размер этого буфера по умолчанию составляет около 64 кб, и его нельзя изменить без перекомпиляции ядра, по крайней мере, в Linux. Каналы также являются однонаправленными, что означает, что вам придется поддерживать пару каналов в каждом процессе, один для чтения и один для записи.

Сокеты Unix имеют настраиваемый размер буфера отправки и более продвинутый программный интерфейс.

1. Каналы не дают никаких гарантий в отношении подобных операций чтения / записи, и легко создать простую программу, чтобы показать, что можно read комбинировать несколько write вызовов. (См.: pastebin.com/LxbreJke ) Кроме того, обычно не следует делать предположений о размере буфера (буфер 64 кб — это довольно недавнее изменение: у меня часто были старые боксеры Linux, поскольку люди сопротивляются обновлению.). Основное различие между каналами и сокетами заключается в том, что канал FIFO является односторонним, сокет Unix — двусторонним.