- Параллельное исполнение в bash, Аноним, 19:41 , 08-Окт-20 (1) –3
Как лучше сделать? Загуглить решение, очевидно же. Научиться гуглить и читать документацию.
- Параллельное исполнение в bash, Аноним, 19:42 , 08-Окт-20 (2)
> Как лучше сделать? Загуглить решение, очевидно же. Научиться гуглить и читать документацию. Если бы это было так просто, я бы уже давно сделал.
- Параллельное исполнение в bash, Licha Morada, 20:55 , 08-Окт-20 (3)
- Параллельное исполнение в bash, Аноним, 21:10 , 08-Окт-20 (4)
Мне нужен раздельный вывод (т.е. табы или разделить одно окно и пулять выхлоп каждого процесса раздельно), мне нужно произвольное число процессов (по числу ядер). Это основное. Если синхронизация только в родительском процессе, нужно контролировать статус фоновых процессов и опционально управлять ими посредством сигналов (достаточно будет получить код завершения, текстовый ipc через фс я уже сделал и тут мне не нужно передавать данные между процессами). Управление фоновыми процессами через job/wait показалось мне очень не надёжным, как пример, после завершения родителя порождённые процессы не спешат умирать и нет никакой возможности узнать их пиды для убийства (я решил этот вопрос, но не совсем так, как хотелось бы), постоянные проблемы с состоянием гонки и синхронизацией (необходимо это учитывать, если где-то в процессе исполнения возникла ошибка).
- Параллельное исполнение в bash, Аноним, 21:32 , 08-Окт-20 (5)
Да, от файлов с выводом, который я буду читать в основном процессе, тоже хотелось бы отказаться в идеале, я правда не представляю как.
- Параллельное исполнение в bash, Аноним, 22:36 , 08-Окт-20 (6)
Чтобы такое сделать, вам нужно книжку по шелл-скриптингу прочитать. На самом деле только научиться перенаправлять вывод. Например, ./run > file$x.out & Пид лежит в специальной переменной, которую можно прочитать после запуска.Если не хотите все это изучать - наймите того, кто уже это сделал.
- Параллельное исполнение в bash, Аноним, 22:43 , 08-Окт-20 (8)
Невозможно узнать идентификаторы потомков потомка, если только они сами не запишут их в какой-нибудь файл. Давайте по существу. И мне нужен выводу в реальном времени, а не после завершения.
- Параллельное исполнение в bash, Аноним, 03:42 , 09-Окт-20 (11)
> Невозможно узнать идентификаторы потомков потомка, если только они сами не запишут их > в какой-нибудь файл. Давайте по существу. И мне нужен выводу в > реальном времени, а не после завершения.Если вы сами не компетентны, хотя бы не учите других. Пожалуйста.
- Параллельное исполнение в bash, Аноним, 04:13 , 09-Окт-20 (12)
Извините, а где я кого-то учил? И из чего можно сделать выводы о моей компетенции? Вот о Вашей уже сложилось определённое мнение на основании ответов в данной теме.
- Параллельное исполнение в bash, Аноним, 11:45 , 09-Окт-20 (13)
> Извините, а где я кого-то учил?Ну вот же вы утверждаете, что нельзя узнать пид, если он не был сохранен в файл самим процессом. Кто-то может перенять заблуждение. Прочитайте документацию по башу. Будете знать и как пид запущенного процесса получить, и как параллельно процессы запускать.
- Параллельное исполнение в bash, Аноним, 19:05 , 09-Окт-20 (15)
> Ну вот же вы утверждаете, что нельзя узнать пид, если он не > был сохранен в файл самим процессом. Кто-то может перенять заблуждение. > Прочитайте документацию по башу. Будете знать и как пид запущенного процесса получить, > и как параллельно процессы запускать.Так это было указание на очевиднейшую безграмотность, я не пытался ничему учить. Но, раз настаиваете… Если сейчас покажете, как получить идентификатор потомка дочернего процесса (чтобы тому можно было отправить сигнал, например), я признаю, что часами долбился в глазки, вместо того, чтобы больше экспериментировать и найти всё-таки подходящий способ. Поскольку единственное решение, найденное мной, заключается в убийстве себя, и тогда все потомки, включая деток и внучек, отправляются на тот свет вместе с нами достаточно быстро, но только в случае, если те ещё не успели разбежаться во все стороны (потому что тогда они уже успешно демонизируются и сделать с ними ничего не получится, а сигналы они замечательно проигнорируют в одном случае из 10). И упомянутая мной запись всех айди в файл и управление ими из мейна тоже не самый универсальный метод -- если sigint прийдёт не вовремя, программа в лучшем случае устроит что-то в духе rm -rf *, а дочерним процессам прилетят случайные сигналы (или не прилетят вовсе, если те уже перестали быть дочерними). В противном случае, дверь вон в той стороне, выйдите вон, и по возможности больше не отвечайте на вопросы, в которых ни черта не смыслите, или хотя бы не делайте вид, что в чём-то разбираетесь. Спасибо.
- Параллельное исполнение в bash, Аноним, 21:56 , 09-Окт-20 (22)
Пиды процессов внуков только через системные утилиты, работающие с процессами. Либо вы шлете сигнал дочке, а она его обрабатывает, делая что-то с внуками. Но проще так не делать и перепроектировать логику.Скрипт, который будет делать то, что вам надо, это примерно строк 10, может быть 20. В нем будут такие вещи, как for in, nproc, &, wait, возможно $!, trap. Отлично гуглятся все вопросы, которые могут возникнуть при написании. Во всяком случае, по-английски все документировано и разжевано. Вам принципиально, чтобы какой-то русскоязычный васёк за вас скрипт написал? Фетиш какой-то? Уже два дня побираетесь, можно было уже пару раз перечитать доку по башу вдоль и поперек.
- Параллельное исполнение в bash, Аноним, 22:32 , 09-Окт-20 (23)
Проблема в том, что "системные утилиты, работающие с процессами", не могут предоставить информации, не имеющейся у ядра. А сканирование всех процессов на предмет ближайшего предка (если он ещё не потерян!) -- это не самое лучшее решение, подверженное всё той же гонке и случайным плавающим багам. Все мои попытки передавать сигнал по цепочке завершились тем, что в одном случае из десяти (или ста), процессы их игнорировали и успешно демонизировались. Перепроектировать логику не получится. Если тот же sleep запущен, он будет продолжать висеть под инитом, пока его не убьют, или он не закончится сам.Вопрос был как организовать и перенаправить вывод в удобоваримом виде, а не как запустить несколько процессов параллельно. Вопрос, как принудительно завершать потомков при (внезапном) завершении мейна мы не рассматриваем, очевидно, что адекватного решения для него в интернете просто нет.
- Параллельное исполнение в bash, Аноним, 18:42 , 12-Окт-20 (25)
Выдумываете себе проблемы, чтобы потом героически их превозмогать. Сраному скрипту в кроне - нужны данные о процессах уровня ядра! Линукс Торвальдс должен срочно сделать новые апи, чтобы вы смоги решить свои задачи...Вам нужно запустить какие-то джобы в параллель и обработать их ошибки, если что-то пошло не так. Для этого не нужно никакого IPC при условии правильного проектирования. Если не можете придумать, как это сделать без абсурдных переусложнений - наймите системного администратора.
- Параллельное исполнение в bash, Аноним, 19:19 , 12-Окт-20 (26)
Там задача была ждать данные в основном потоке и накапливать, валидировать, и сбрасывать на диск каждые N времени в дополнительном фоновом основываясь на ряде условий. Какой ещё крон? Использовать тут крон это напрашиваться на проблемы -- при убийстве скрипта некому будет его отключить. Полагаю, ваши скрипты очень грязные.Но это не имеет никакого отношения к текущей проблеме. Сейчас меня интересует организация красивого вывода с индикацией работы скрипта (без ncurses). Простое "решение" у меня и так есть, это find . -name "*" -print0 | xargs -0 -n 1 -P "$(nproc)" -I '{}' script '{}' однако вывод превращаеся в мешанину. "Классическое" решение это отключить вывод, но меня оно не устраивает.
- Параллельное исполнение в bash, Аноним, 22:43 , 08-Окт-20 (9) +1
- Параллельное исполнение в bash, system, 15:33 , 09-Окт-20 (14)
> С год назад хотел организовать параллельное исполнение, но что-то не вышло, и > я оставил всё на одном ядре. Очень медленно. Как лучше его > сделать? Хотя бы без синхронизации (синхронизация фоновых жобов развлечение ещё то, > не хочу городить грязь, где она не нужна). > Один. Нужно просто запускать ещё 1 процесс по процессу на ядро как > только завершился предыдущий и пока есть работа. > Два. Нужно организовать вывод из всех скриптов, разделить экран по числу ядер > в tmux или можно придумать что-нибудь ещё? > Жду ваших советов и предложений, спасибо.пишешь простейший Makefile + make -jX
- Параллельное исполнение в bash, Аноним, 19:16 , 09-Окт-20 (16)
Это заявка на победу, я думаю, стоит уже взять parallel в таком случае. Но мне хотелось бы решить это без perl. Я могу всё это сделать красиво в python, там и ipc есть нормальный, и самые разные варианты запускать процессы, но задача обойтись средствами баша. Собственно, в ОП перечислен алгоритм моего питон однострочника запускающего окно и направляющего выводы youtube-dl в него. Там проблема, что он запускался только под conemu, а мне сейчас нужно что-то более универсальное (хотя вариант с konsole готов рассмотреть, хотелось бы переключать на соседний таб с разделением на области, но, полагаю, принудительный запуск дополнительного окна с tmux тоже не плохой вариант).
- Параллельное исполнение в bash, pavel_simple., 19:23 , 09-Окт-20 (17)
> Это заявка на победу, я думаю, стоит уже взять parallel в таком > случае. Но мне хотелось бы решить это без perl. Я могу > всё это сделать красиво в python, там и ipc есть нормальный, > и самые разные варианты запускать процессы, но задача обойтись средствами баша. > Собственно, в ОП перечислен алгоритм моего питон однострочника запускающего окно и > направляющего выводы youtube-dl в него. Там проблема, что он запускался только > под conemu, а мне сейчас нужно что-то более универсальное (хотя вариант > с konsole готов рассмотреть, хотелось бы переключать на соседний таб с > разделением на области, но, полагаю, принудительный запуск дополнительного окна с tmux > тоже не плохой вариант).xargs + screen/tmux
- Параллельное исполнение в bash, Аноним, 19:49 , 09-Окт-20 (18)
> xargs + screen/tmux Я вспомнил, чем мне не подошёл этот вариант. Там вроде бы можно было только отправлять команду на исполнение в панели, т.е. запуск новых процессов нонстоп (это то, что я использовал в конечном итоге, но тут это не подходит, хотя и можно набросать отдельный однострочник, запускающий этот скрипт -- мне как раз хотелось отказаться от по-файлового исполнения, слишком много времени на запуск уходит, особенно на "нелинуксе"). Либо добавлять текст (вывод) в панель уже после завершения, но нельзя было прицепить stderr/stdout/stdin запущенного процесса (и его потомков) к панели tmux и переключать его на вывод следующего процесса после завершения первого.
- Параллельное исполнение в bash, Аноним, 20:06 , 09-Окт-20 (19)
В связи с чем вопрос. Можно ли как-то подцепить вывод форка себя (и автоматом всех потомков форка) к шеллу, запущенному в панели tmux?
- Параллельное исполнение в bash, Аноним, 20:37 , 09-Окт-20 (20)
> В связи с чем вопрос. Можно ли как-то подцепить вывод форка себя > (и автоматом всех потомков форка) к шеллу, запущенному в панели tmux? Так, допустим, можно перенаправить все три потока для каждого процесса в именованные трубы (не проверял ввод, но вывод определённо будет работать), т.е. нам как минимум всё ещё необходимо сохранить список дочерних процессов (может и работать, при условии, что те не будут рекурсивно форкать себя и терять потомков), но мы всё ещё подвержены состояниям гонки и неадекватной реакции на сигналы. Тут тут возникает вопрос с тем, что tmux сам по себе и он может обидеться, когда мы начинаем взаимодействовать с шеллом в обход него, т.е. у tmux надо как-то отнять контроль над выводом (вводом) запущенных им шеллов.
- Параллельное исполнение в bash, Аноним, 21:01 , 09-Окт-20 (21)
Форк ведь может переопределить дескрипторы для себя? Это никак не должно затрагивать родительский процесс.
- Параллельное исполнение в bash, Аноним, 03:14 , 11-Окт-20 (24)
Какая же гадость этот parallel. Он поддерживает вывод в tmux (казалось бы что ещё нужно!) но запускает при этом 100 раз одновременно и ломает вывод консоли. Ещё и наспамила в консоль своим бредом сначала, автор очевидный аутист.Ну в принципе вот это наверное, да. Утянул себе нужное, надо закончить и посмотреть, как будет, а то xargs конечно нормально работает, но мешанина вывода совершенно нечитаемая. https://gist.github.com/mlgill/ad2693f17aaa720ef777
|