ОК.
>read -t 0.1Ну неплохая эмуляция sleep 0.1, жаль шо bash, а занчит в ash/dash не применима.
>Так, а ты у нас тут кто?
Ну как видиш формально тоже, но по факту знакомился с миром unix от лица busybox и мобильного дистрибутива времен 2003-2005 года (на ядре Linux 2.6). По этому у меня другие взгляды. И да, там ОС запускается на скриптах. :)
>Вот на это обрати внимание особенно. Если у тебя сильно ограничены ресурсы, то очень вероятно, что shell в данном случае -- это не правильный инструмент.
Ну знаеш, есть фанаты питона, есть фанаты web, а есть фанаты shell. =)
Я понимаю шо C намного быстрее сам по себе, но зачем его долго изучать если shell полностью может выполнить задачу не хуже? Это отличный простой язык который в паре с утилитами бинарными может очень многое.
По моему лучше уж на shell писать, чем из тела бинарника C++ вызывать утилиты из /bin/.
>/bin/sleep -- это как раз coreutils
Смотри, вот такой пример:
read A0 A1 A2 A3 A4 AA </proc/stat
zInterval 100 text | while read out
do
B4="$A4"
read A0 A1 A2 A3 A4 AA </proc/stat
CPUCONTROL
done
В нем функция CPUCONTROL вызывается каждые 0,1 с, а цыкл не плодит новых процесов постоянно, как было бы с sleep — это благодаря генератору интервалов zInterval который с паузой в 0,1 с просто печатает "text".
>Какие процессы, какие 50% CPU?
Каждый вызов sleep или usleep (который щас не нужен из за возможности sleep 0.0001) запускает новый процес, и это создает реальную и ощутимую нагрузку на ЦП при зацыкливании и милисекундных паузах.
И если на мощных ЦП ПК это почти не ощущается, то PID запущеных програм вида 54643543428 очень трудно воспринимать.
Не знаю как на современном Linux, но на 2.6 ядре отщет новых PID начинался сначала через лимит max pid, то есть 4485 может быть запущеным после 491448, а 145 до.
ПС: вот дефис на укр. раскладке, возьми: — :D