Зачем использовать именованный канал вместо файла?
Недавно я прочитал про именованные каналы, и я не мог понять, почему они существуют. Я читал где-то, что использование именованного канала менее трудоемко, чем использование файла.
Почему это так? Именованные каналы также должны быть сохранены в памяти ( и, возможно, поменялись местами, как файлы). Насколько я вижу, они должны получить inode, на который должен ссылаться текущий каталог, так же как и файлы. Кроме того, они должны быть удалены программистом, как файлы.
Итак, где же преимущество?
3 ответа
Верно, что вы не будете использовать системную память, но тот факт, что вы не используете процессор в вашем примере, - это только потому, что вы не читаете канал, поэтому процесс ждет.
Рассмотрим следующий:
mkfifo /tmp/testpipe
tar cvf - / | gzip > /tmp/testpipe
Теперь откройте новую консоль и запустите:
watch -n 1 'ps u -P $(pidof tar)
И на третьей консоли:
cat /tmp/testpipe > /dev/null
Если вы посмотрите на часах cmd (2-й семестр) это покажет увеличение потребления процессора!
-
1Этот ответ о ответе c0rp – wjandrea 21 May 2017 в 08:38
Вы можете позволить программе оставаться неподвижным и прослушивать именованный канал для какого-либо внешнего события. Как только произойдет внешнее событие (например, приход некоторых новых данных), это может быть обнаружено другой программой, которая, в свою очередь, открывает трубу для записи, записывая соответствующие данные события в трубу. Когда выдается инструкция закрытия, программа прослушивания будет получать поток данных через трубу через инструкцию чтения и готова обработать то, что она получила. Не забудьте закрыть трубку после прочтения содержимого. Программа прослушивания также может возвращать результаты ее обработки через то же самое или через другой именованный канал. Такие межпрограммные сообщения очень удобны время от времени.
Вот пример использования, когда именованные каналы могут сэкономить вам много времени, удалив I / O.
Предположим, что у вас есть BigFile, например, 10G.
You также есть расколы этого BigFile в кусках 1G, BigFileSplit_01 до BigFile_Split_10.
Теперь у вас есть сомнения в правильности BigFileSplit_05
Наивно, без именованных каналов, вы создали бы новый разорвать с BigFile и сравнить:
dd if=BigFile of=BigFileSplitOrig_05 bs=1G skip=4 count=1
diff -s BigFileSplitOrig_05 BigFileSplit_05
rm BigFileSplitOrig_05
С именованными каналами вы бы сделали
mkfifo BigFileSplitOrig_05
dd if=BigFile of=BigFileSplitOrig_05 bs=1G skip=4 count=1 &
diff -s BigFileSplitOrig_05 BigFileSplit_05
rm BigFileSplitOrig_05
Это может показаться на первый взгляд большой разницей ... но со временем разница
экономит ваше время, удаляя ввод / вывод.
dd: читать 1G / write 1G (1) diff: читать 2G rm: свободные выделенные кластеры / удалить запись в каталогеВариант 2:
dd: читать 1G / write 1G (1) diff: читать 2G diff: read 2GИтак, в основном именованный канал сохраняет здесь чтение и запись 1G плюс некоторую очистку файловой системы (поскольку мы ничего не писали файловой системе, но пустой фито-кивок e).
Не делать ввода-вывода, особенно пишет, также хорошо, чтобы избежать износа ваших дисков. Это еще более интересно, когда вы работаете с SSD, так как у них ограниченное количество записей до того, как клетки умирают.
(1) Очевидно, что другой вариант заключается в создании этого временного файла в ОЗУ, например, если / tmp устанавливается в ОЗУ (tmpfs). Тем не менее, вы будете ограничены размером RAM-диска, тогда как «именованный трюк» не имеет ограничений.