Вариант для распечатки		Пред. тема | След. тема
Форум Программирование под UNIX (Shell скрипты)
Изначальное сообщение		[ Отслеживать ]

"Параллельное исполнение в bash"	+/–
Сообщение от Аноним (0), 08-Окт-20, 19:15
С год назад хотел организовать параллельное исполнение, но что-то не вышло, и я оставил всё на одном ядре. Очень медленно. Как лучше его сделать? Хотя бы без синхронизации (синхронизация фоновых жобов развлечение ещё то, не хочу городить грязь, где она не нужна). Один. Нужно просто запускать ещё 1 процесс по процессу на ядро как только завершился предыдущий и пока есть работа. Два. Нужно организовать вывод из всех скриптов, разделить экран по числу ядер в tmux или можно придумать что-нибудь ещё? Жду ваших советов и предложений, спасибо.
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Параллельное исполнение в bash"	–3 +/–
Сообщение от Аноним (1), 08-Окт-20, 19:41
Как лучше сделать? Загуглить решение, очевидно же. Научиться гуглить и читать документацию.
Ответить | Правка | Наверх | Cообщить модератору

	2. "Параллельное исполнение в bash"	+/–
	Сообщение от Аноним (0), 08-Окт-20, 19:42
	> Как лучше сделать? Загуглить решение, очевидно же. Научиться гуглить и читать документацию. Если бы это было так просто, я бы уже давно сделал.
	Ответить | Правка | Наверх | Cообщить модератору

	7. "Параллельное исполнение в bash"	+/–
	Сообщение от Аноним (1), 08-Окт-20, 22:37
	Это проще, чем побираться по форумам.
	Ответить | Правка | Наверх | Cообщить модератору

	10. "Параллельное исполнение в bash"	+/–
	Сообщение от Аноним (0), 08-Окт-20, 22:45
	> Это проще, чем побираться по форумам. Уважаемый, у Вас тут синдром Даннинга-Крюгера.
	Ответить | Правка | Наверх | Cообщить модератору

3. "Параллельное исполнение в bash"	+/–
Сообщение от Licha Morada (ok), 08-Окт-20, 20:55
> С год назад хотел организовать параллельное исполнение, но что-то не вышло, и > я оставил всё на одном ядре. Очень медленно. Как лучше его > сделать? У Вивека посмотрите. https://www.cyberciti.biz/faq/how-to-run-command-or-code-in-.../
Ответить | Правка | Наверх | Cообщить модератору

	4. "Параллельное исполнение в bash"	+/–
	Сообщение от Аноним (0), 08-Окт-20, 21:10
	Мне нужен раздельный вывод (т.е. табы или разделить одно окно и пулять выхлоп каждого процесса раздельно), мне нужно произвольное число процессов (по числу ядер). Это основное. Если синхронизация только в родительском процессе, нужно контролировать статус фоновых процессов и опционально управлять ими посредством сигналов (достаточно будет получить код завершения, текстовый ipc через фс я уже сделал и тут мне не нужно передавать данные между процессами). Управление фоновыми процессами через job/wait показалось мне очень не надёжным, как пример, после завершения родителя порождённые процессы не спешат умирать и нет никакой возможности узнать их пиды для убийства (я решил этот вопрос, но не совсем так, как хотелось бы), постоянные проблемы с состоянием гонки и синхронизацией (необходимо это учитывать, если где-то в процессе исполнения возникла ошибка).
	Ответить | Правка | Наверх | Cообщить модератору

	5. "Параллельное исполнение в bash"	+/–
	Сообщение от Аноним (0), 08-Окт-20, 21:32
	Да, от файлов с выводом, который я буду читать в основном процессе, тоже хотелось бы отказаться в идеале, я правда не представляю как.
	Ответить | Правка | Наверх | Cообщить модератору

	6. "Параллельное исполнение в bash"	+/–
	Сообщение от Аноним (1), 08-Окт-20, 22:36
	Чтобы такое сделать, вам нужно книжку по шелл-скриптингу прочитать. На самом деле только научиться перенаправлять вывод. Например, ./run > file$x.out & Пид лежит в специальной переменной, которую можно прочитать после запуска. Если не хотите все это изучать - наймите того, кто уже это сделал.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	8. "Параллельное исполнение в bash"	+/–
	Сообщение от Аноним (0), 08-Окт-20, 22:43
	Невозможно узнать идентификаторы потомков потомка, если только они сами не запишут их в какой-нибудь файл. Давайте по существу. И мне нужен выводу в реальном времени, а не после завершения.
	Ответить | Правка | Наверх | Cообщить модератору

	11. "Параллельное исполнение в bash"	+/–
	Сообщение от Аноним (1), 09-Окт-20, 03:42
	> Невозможно узнать идентификаторы потомков потомка, если только они сами не запишут их > в какой-нибудь файл. Давайте по существу. И мне нужен выводу в > реальном времени, а не после завершения. Если вы сами не компетентны, хотя бы не учите других. Пожалуйста.
	Ответить | Правка | Наверх | Cообщить модератору

	12. "Параллельное исполнение в bash"	+/–
	Сообщение от Аноним (0), 09-Окт-20, 04:13
	Извините, а где я кого-то учил? И из чего можно сделать выводы о моей компетенции? Вот о Вашей уже сложилось определённое мнение на основании ответов в данной теме.
	Ответить | Правка | Наверх | Cообщить модератору

	13. "Параллельное исполнение в bash"	+/–
	Сообщение от Аноним (1), 09-Окт-20, 11:45
	> Извините, а где я кого-то учил? Ну вот же вы утверждаете, что нельзя узнать пид, если он не был сохранен в файл самим процессом. Кто-то может перенять заблуждение. Прочитайте документацию по башу. Будете знать и как пид запущенного процесса получить, и как параллельно процессы запускать.
	Ответить | Правка | Наверх | Cообщить модератору

	15. "Параллельное исполнение в bash"	+/–
	Сообщение от Аноним (0), 09-Окт-20, 19:05
	> Ну вот же вы утверждаете, что нельзя узнать пид, если он не > был сохранен в файл самим процессом. Кто-то может перенять заблуждение. > Прочитайте документацию по башу. Будете знать и как пид запущенного процесса получить, > и как параллельно процессы запускать. Так это было указание на очевиднейшую безграмотность, я не пытался ничему учить. Но, раз настаиваете… Если сейчас покажете, как получить идентификатор потомка дочернего процесса (чтобы тому можно было отправить сигнал, например), я признаю, что часами долбился в глазки, вместо того, чтобы больше экспериментировать и найти всё-таки подходящий способ. Поскольку единственное решение, найденное мной, заключается в убийстве себя, и тогда все потомки, включая деток и внучек, отправляются на тот свет вместе с нами достаточно быстро, но только в случае, если те ещё не успели разбежаться во все стороны (потому что тогда они уже успешно демонизируются и сделать с ними ничего не получится, а сигналы они замечательно проигнорируют в одном случае из 10). И упомянутая мной запись всех айди в файл и управление ими из мейна тоже не самый универсальный метод -- если sigint прийдёт не вовремя, программа в лучшем случае устроит что-то в духе rm -rf *, а дочерним процессам прилетят случайные сигналы (или не прилетят вовсе, если те уже перестали быть дочерними). В противном случае, дверь вон в той стороне, выйдите вон, и по возможности больше не отвечайте на вопросы, в которых ни черта не смыслите, или хотя бы не делайте вид, что в чём-то разбираетесь. Спасибо.
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Параллельное исполнение в bash"	+/–
	Сообщение от Аноним (1), 09-Окт-20, 21:56
	Пиды процессов внуков только через системные утилиты, работающие с процессами. Либо вы шлете сигнал дочке, а она его обрабатывает, делая что-то с внуками. Но проще так не делать и перепроектировать логику. Скрипт, который будет делать то, что вам надо, это примерно строк 10, может быть 20. В нем будут такие вещи, как for in, nproc, &, wait, возможно $!, trap. Отлично гуглятся все вопросы, которые могут возникнуть при написании. Во всяком случае, по-английски все документировано и разжевано. Вам принципиально, чтобы какой-то русскоязычный васёк за вас скрипт написал? Фетиш какой-то? Уже два дня побираетесь, можно было уже пару раз перечитать доку по башу вдоль и поперек.
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Параллельное исполнение в bash"	+/–
	Сообщение от Аноним (0), 09-Окт-20, 22:32
	Проблема в том, что "системные утилиты, работающие с процессами", не могут предоставить информации, не имеющейся у ядра. А сканирование всех процессов на предмет ближайшего предка (если он ещё не потерян!) -- это не самое лучшее решение, подверженное всё той же гонке и случайным плавающим багам. Все мои попытки передавать сигнал по цепочке завершились тем, что в одном случае из десяти (или ста), процессы их игнорировали и успешно демонизировались. Перепроектировать логику не получится. Если тот же sleep запущен, он будет продолжать висеть под инитом, пока его не убьют, или он не закончится сам. Вопрос был как организовать и перенаправить вывод в удобоваримом виде, а не как запустить несколько процессов параллельно. Вопрос, как принудительно завершать потомков при (внезапном) завершении мейна мы не рассматриваем, очевидно, что адекватного решения для него в интернете просто нет.
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Параллельное исполнение в bash"	+/–
	Сообщение от Аноним (1), 12-Окт-20, 18:42
	Выдумываете себе проблемы, чтобы потом героически их превозмогать. Сраному скрипту в кроне - нужны данные о процессах уровня ядра! Линукс Торвальдс должен срочно сделать новые апи, чтобы вы смоги решить свои задачи... Вам нужно запустить какие-то джобы в параллель и обработать их ошибки, если что-то пошло не так. Для этого не нужно никакого IPC при условии правильного проектирования. Если не можете придумать, как это сделать без абсурдных переусложнений - наймите системного администратора.
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Параллельное исполнение в bash"	+/–
	Сообщение от Аноним (0), 12-Окт-20, 19:19
	Там задача была ждать данные в основном потоке и накапливать, валидировать, и сбрасывать на диск каждые N времени в дополнительном фоновом основываясь на ряде условий. Какой ещё крон? Использовать тут крон это напрашиваться на проблемы -- при убийстве скрипта некому будет его отключить. Полагаю, ваши скрипты очень грязные. Но это не имеет никакого отношения к текущей проблеме. Сейчас меня интересует организация красивого вывода с индикацией работы скрипта (без ncurses). Простое "решение" у меня и так есть, это find . -name "*" -print0 | xargs -0 -n 1 -P "$(nproc)" -I '{}' script '{}' однако вывод превращаеся в мешанину. "Классическое" решение это отключить вывод, но меня оно не устраивает.
	Ответить | Правка | Наверх | Cообщить модератору

	9. "Параллельное исполнение в bash"	+1 +/–
	Сообщение от Аноним (-), 08-Окт-20, 22:43
	> Если не хотите все это изучать - наймите того, кто уже это > сделал. Вот этого нельзя допустить ! Держи друг Аноним https://github.com/dustinblackman/tcon
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

14. "Параллельное исполнение в bash"	+/–
Сообщение от system (??), 09-Окт-20, 15:33
> С год назад хотел организовать параллельное исполнение, но что-то не вышло, и > я оставил всё на одном ядре. Очень медленно. Как лучше его > сделать? Хотя бы без синхронизации (синхронизация фоновых жобов развлечение ещё то, > не хочу городить грязь, где она не нужна). > Один. Нужно просто запускать ещё 1 процесс по процессу на ядро как > только завершился предыдущий и пока есть работа. > Два. Нужно организовать вывод из всех скриптов, разделить экран по числу ядер > в tmux или можно придумать что-нибудь ещё? > Жду ваших советов и предложений, спасибо. пишешь простейший Makefile + make -jX
Ответить | Правка | Наверх | Cообщить модератору

	16. "Параллельное исполнение в bash"	+/–
	Сообщение от Аноним (0), 09-Окт-20, 19:16
	Это заявка на победу, я думаю, стоит уже взять parallel в таком случае. Но мне хотелось бы решить это без perl. Я могу всё это сделать красиво в python, там и ipc есть нормальный, и самые разные варианты запускать процессы, но задача обойтись средствами баша. Собственно, в ОП перечислен алгоритм моего питон однострочника запускающего окно и направляющего выводы youtube-dl в него. Там проблема, что он запускался только под conemu, а мне сейчас нужно что-то более универсальное (хотя вариант с konsole готов рассмотреть, хотелось бы переключать на соседний таб с разделением на области, но, полагаю, принудительный запуск дополнительного окна с tmux тоже не плохой вариант).
	Ответить | Правка | Наверх | Cообщить модератору

	17. "Параллельное исполнение в bash"	+/–
	Сообщение от pavel_simple. (?), 09-Окт-20, 19:23
	> Это заявка на победу, я думаю, стоит уже взять parallel в таком > случае. Но мне хотелось бы решить это без perl. Я могу > всё это сделать красиво в python, там и ipc есть нормальный, > и самые разные варианты запускать процессы, но задача обойтись средствами баша. > Собственно, в ОП перечислен алгоритм моего питон однострочника запускающего окно и > направляющего выводы youtube-dl в него. Там проблема, что он запускался только > под conemu, а мне сейчас нужно что-то более универсальное (хотя вариант > с konsole готов рассмотреть, хотелось бы переключать на соседний таб с > разделением на области, но, полагаю, принудительный запуск дополнительного окна с tmux > тоже не плохой вариант). xargs + screen/tmux
	Ответить | Правка | Наверх | Cообщить модератору

	18. "Параллельное исполнение в bash"	+/–
	Сообщение от Аноним (0), 09-Окт-20, 19:49
	> xargs + screen/tmux Я вспомнил, чем мне не подошёл этот вариант. Там вроде бы можно было только отправлять команду на исполнение в панели, т.е. запуск новых процессов нонстоп (это то, что я использовал в конечном итоге, но тут это не подходит, хотя и можно набросать отдельный однострочник, запускающий этот скрипт -- мне как раз хотелось отказаться от по-файлового исполнения, слишком много времени на запуск уходит, особенно на "нелинуксе"). Либо добавлять текст (вывод) в панель уже после завершения, но нельзя было прицепить stderr/stdout/stdin запущенного процесса (и его потомков) к панели tmux и переключать его на вывод следующего процесса после завершения первого.
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Параллельное исполнение в bash"	+/–
	Сообщение от Аноним (0), 09-Окт-20, 20:06
	В связи с чем вопрос. Можно ли как-то подцепить вывод форка себя (и автоматом всех потомков форка) к шеллу, запущенному в панели tmux?
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Параллельное исполнение в bash"	+/–
	Сообщение от Аноним (0), 09-Окт-20, 20:37
	> В связи с чем вопрос. Можно ли как-то подцепить вывод форка себя > (и автоматом всех потомков форка) к шеллу, запущенному в панели tmux? Так, допустим, можно перенаправить все три потока для каждого процесса в именованные трубы (не проверял ввод, но вывод определённо будет работать), т.е. нам как минимум всё ещё необходимо сохранить список дочерних процессов (может и работать, при условии, что те не будут рекурсивно форкать себя и терять потомков), но мы всё ещё подвержены состояниям гонки и неадекватной реакции на сигналы. Тут тут возникает вопрос с тем, что tmux сам по себе и он может обидеться, когда мы начинаем взаимодействовать с шеллом в обход него, т.е. у tmux надо как-то отнять контроль над выводом (вводом) запущенных им шеллов.
	Ответить | Правка | Наверх | Cообщить модератору

	21. "Параллельное исполнение в bash"	+/–
	Сообщение от Аноним (0), 09-Окт-20, 21:01
	Форк ведь может переопределить дескрипторы для себя? Это никак не должно затрагивать родительский процесс.
	Ответить | Правка | Наверх | Cообщить модератору

24. "Параллельное исполнение в bash"	+/–
Сообщение от Аноним (0), 11-Окт-20, 03:14
Какая же гадость этот parallel. Он поддерживает вывод в tmux (казалось бы что ещё нужно!) но запускает при этом 100 раз одновременно и ломает вывод консоли. Ещё и наспамила в консоль своим бредом сначала, автор очевидный аутист. Ну в принципе вот это наверное, да. Утянул себе нужное, надо закончить и посмотреть, как будет, а то xargs конечно нормально работает, но мешанина вывода совершенно нечитаемая. https://gist.github.com/mlgill/ad2693f17aaa720ef777
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема