Нет. Конвейер — это -односторонний канал связи. Вот почему это называется «конвейером»; вы не смогли бы отправить нефть обратно по трубопроводу, даже если бы попытались.
Однако, если bar.js также должен взаимодействовать с foo.js, у вас есть несколько вариантов:
foo.js
и bar.js
по отдельности (, т. е. больше не передавайте вывод foo.js в bar.js ). Я не знаю, как вы это делаете из узла, но, по сути, сокет домена unix — это сетевой сокет, который использует имена файлов, а не IP-адреса, и работает внутри ядра. Сокеты предназначены для двунаправленной связи, но требуют большей настройки, чем простой канал (, например, прослушивающий сокет может взаимодействовать с несколькими экземплярами bar.js ). Вы можете найти сокеты домена unix в файловой системе, но это не является строго необходимым (, и действительно, Linux позволяет создавать сокет домена unix без следа в файловой системе ). mkfifo
для создания именованного канала (или используйте какой-либо API узла для его создания, если он существует; опять же, я не знаю узел ). Затем в foo.js
откройте этот именованный канал и прочитайте из него. Ваш скрипт bar.js
может открывать тот же именованный канал и писать в него.К последнему будет проще всего перейти, так как вы по-прежнему используете файловый ввод-вывод (открытие именованного канала требует открытия файла в файловой системе ), но все равно будет однонаправленным (, хотя вы иметь два канала, по одному в каждом направлении ). Первый немного чище, а также позволяет вам легче перенести один из двух сценариев на другой хост, если это когда-либо понадобится.
В любом случае, если ваши сценарии теперь взаимодействуют в двух направлениях, то для ясности я бы посоветовал вам запускать их как отдельные процессы, а не связывать один процесс с другим. ИМХО, теперь они равноправные партнеры, и ваша командная строка должна показать это. Это всего лишь деталь, и, конечно, технически не требуется.
Точно не знаю.. но похоже вам может понадобиться strace...
Пример:
Вот, скажем, если у меня есть процесс с идентификатором процесса 1055, то сделайте что-то вроде этого:
neo $ sudo strace -w -c -p1055
strace: Process 1055 attached
^Cstrace: Process 1055 detached
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
77.38 5.738820 534 10730 read
5.35 0.396752 114 3480 clone
4.17 0.309514 10 30741 rt_sigprocmask
2.31 0.171203 13 12761 close
1.56 0.115981 16 6960 3480 wait4
1.47 0.108800 10 10441 rt_sigaction
1.43 0.106307 8 11890 fcntl
0.98 0.072344 19 3770 openat
0.86 0.063769 18 3480 write
0.85 0.062820 18 3480 pipe
0.84 0.062443 15 4060 dup2
0.67 0.049338 9 5220 lseek
0.57 0.042007 11 3770 3770 ioctl
0.49 0.036669 10 3480 rt_sigreturn
0.47 0.035150 10 3480 fchmod
0.29 0.021420 12 1740 unlink
0.25 0.018666 10 1740 getpid
0.06 0.004745 16 290 stat
подробнее читайте здесь:
man strace
а также здесь:
Я не совсем уверен, что это то, о чем вы спрашиваете, но это похоже на /usr/bin/time
и измеряет только настенные часы:
#!/bin/bash
start=$(date +%s%N)
"$@"
end=$(date +%s%N)
echo "$(($end - $start)) nanoseconds elapsed"
Сохраните его в wallclock
и запустите, например, с
$./wallclock sleep 1
1006622540 nanoseconds elapsed
Я подозреваю, что вы найдетеperf timechart
очень полезным. По умолчанию он записывает состояние процессора и процесса и рисует диаграмму, показывающую, как это состояние меняется с течением времени :
Вверху показана занятость ЦП, а внизу — процессы: синий означает «выполняется», желтый означает, что процесс ожидает ЦП, красный означает, что процесс заблокирован при вводе-выводе, серый означает, что процесс находится в спящем режиме. perf timechart
выводит SVG, который можно масштабировать до любого желаемого уровня детализации.
Он также может отслеживать ввод-вывод (диска и сети )и филиалов.
perf
содержит другие модули, которые помогут изучить детали; perf record
можно записывать временную метку и информацию о текущем времени -, используя любые интересующие вас события (, если ваша система их поддерживает ).