LINUX.ORG.RU

Каналы, stdin, stdout - несколько вопросов

 , , , ,


0

3

1. Есть ли накладные расходы при соединении stdin и stdout 2-ух различных программ с помощью bash'а? Насколько они ничтожны?
2. Полагаю, первой программе без разницы, куда выплевывать результат: в память или в stdout, второй программе всё равно придется откуда-нибудь считывать. Верно ли утверждение?
3. Сравните способ из 1-ого пункта с прямым вызовом функции из кода и с вызовом из библиотеки.
4. Именованные каналы технически отличаются чем-нибудь от анонимных?



Последнее исправление: sharkvi (всего исправлений: 1)

2. Полагаю, первой программе без разницы, куда выплевывать результат: в память или в stdout, второй программе всё равно придется откуда-нибудь считывать. Верно ли утверждение?

Не совсем. Если это именно stdout, то вывод будет намного медленнее из-за задержки при печати. Это про сравнение «результат в память». Если это два процесса, соединённые посредством stdout -> stdin, то задержки будут намного меньше, но большой объём данных через pipe я бы всё равно не гонял.

3. Сравните способ из 1-ого пункта с прямым вызовом функции из кода и с вызовом из библиотеки.

Чем отличается прямой вызов функции от вызова из библиотеки? Почему ты не можешь вызвать функцию из библиотеки?

4. Именованные каналы технически отличаются чем-нибудь от анонимных?

Технически, думаю, ничем. http://unix.stackexchange.com/questions/69057/what-are-the-advantages-of-usin...

UVV ★★★★★
()

3. Сравните способ из 1-ого пункта с прямым вызовом функции из кода и с вызовом из библиотеки.

Взаимодействие через stdout/stdin требует использования системных вызовов read()/write(). Системный вызов, - переключение из пространства пользователя в пространство ядра и обратно, - довольно дорогая операция. Но если вы не будете делать десятки тысяч системных вызовов в секунду, то отличий в производительности не заметите.

Sorcerer ★★★★★
()

Про 1) вангую, что нет накладных расходов - bash не мониторит поток данных.

2) - разница есть, может быть разное поведение приложения в зависимости от того, в терминал идёт вывод, или нет, аналогично со вводом.

Кстати, объясни мне, в чём смысл сокращать слово «двух» до «2-ух»?

tiandrey ★★★★★
()
Последнее исправление: tiandrey (всего исправлений: 2)

1. Есть ли накладные расходы при соединении stdin и stdout 2-ух различных программ с помощью bash'а? Насколько они ничтожны?

Накладные расходы есть всегда, поэтому правильный вопрос должен звучать как «насколько велики накладные расходы по сравнению с ...».

2. Полагаю, первой программе без разницы, куда выплевывать результат: в память или в stdout, второй программе всё равно придется откуда-нибудь считывать. Верно ли утверждение?

Во-первых, взаимодействие через pipe как-бы тоже включает буффер в памяти, поэтому первое утверждение бессмысленно. Второе не верно, ибо если использовать shared memory то никому ничего выплёвывать и считывать вообще не надо.

3. Сравните способ из 1-ого пункта с прямым вызовом функции из кода и с вызовом из библиотеки.

Взаимодействие через pipe само по себе включает вызовы функций, так что не понятно что вы хотите с чем сравнить.

4. Именованные каналы технически отличаются чем-нибудь от анонимных?

Зависит от реализации, но на практике скорее всего нет.

slovazap ★★★★★
()
Ответ на: комментарий от tiandrey

Кстати, объясни мне, в чём смысл сокращать слово «двух» до «2-ух»?

Это ещё и безграмотно. Правильно 2-х, 1-го.

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

если использовать shared memory то никому ничего выплёвывать и считывать вообще не надо.

Каким образом происходит общение с данными из shared memory? В tmpfs создается «общий файл», с которым могут работать несколько процессов - значит ли это, что shared memory эквивалентно сохраненному в памяти потоку пайпа, к которому могут обращаться все процессы без использования системных вызовов? А если несколько типов хранить нужно? Массив в один «общий файл» shared memory, а булевое значение - в другой?

sharkvi
() автор топика

1. Есть ли накладные расходы при соединении stdin и stdout 2-ух различных программ с помощью bash'а? Насколько они ничтожны?

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

2. Полагаю, первой программе без разницы, куда выплевывать результат: в память или в stdout, второй программе всё равно придется откуда-нибудь считывать. Верно ли утверждение?

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

3. Сравните способ из 1-ого пункта с прямым вызовом функции из кода и с вызовом из библиотеки.

Мы сравнили, сын мой. Это гадко, мерзко и подрывает основы государственности. Расскажи мне, как ты дошёл до подобных сравнений? Может быть тебе кто-нибудь посоветовал это делать? Делал ли ты это сам? Даже когда никто не видит? Почему?

4. Именованные каналы технически отличаются чем-нибудь от анонимных?

Сравни идиотов-регистратов на ЛОРе и мудрых анонимусов. Всё неанонимное в чём-то ущербно.

anonymous
()
Ответ на: комментарий от sharkvi

Каким образом происходит общение с данными из shared memory? В tmpfs создается «общий файл»

tmpfs тут не при чём.

с которым могут работать несколько процессов - значит ли это, что shared memory эквивалентно сохраненному в памяти потоку пайпа, к которому могут обращаться все процессы без использования системных вызовов? А если несколько типов хранить нужно? Массив в один «общий файл» shared memory, а булевое значение - в другой?

shared memory - это общая пямять, храните в ней что угодно и как угодно.

slovazap ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.