Bash`wait`命令,等待超过1个PID完成执行

Question

我最近发布了一个问题,询问是否有可能阻止PID重复使用.

到目前为止,答案似乎是否定的.(没关系.)

但是,用户Diego Torres Milano在这个问题上添加了一个答案,我的问题就在于答案.

迭戈回答说,

如果您害怕重复使用PID,如果您等待其他答案解释则不会发生,您可以使用

echo 4194303 > /proc/sys/kernel/pid_max

减少你的恐惧;-)

我实际上并不理解为什么迭戈在4194303这里使用了这个数字,但这是另一个问题.

我的理解是我遇到了以下代码的问题:

for pid in "${PIDS[@]}"
do
    wait $pid
done

问题是我在一个数组中有多个PID,并且for循环将按wait顺序运行命令与数组中的每个PID,但是我不能预测进程将以与它们的PID存储在此数组中相同的顺序完成.

即; 可能发生以下情况:

• 在数组索引0中开始等待PID
• 在数组的索引1中使用PID的进程终止
• 新作业在系统上运行,导致存储在PID阵列的索引1中的PID被重新用于另一个进程
• wait 终止为数组索引0中的PID退出
• 开始在数组索引0中等待PID,除了这是一个不同的过程,我们不知道它是什么
• 重新使用wait当前正在等待的PID的运行过程永远不会终止.也许它是邮件服务器的PID或系统管理员已启动的东西.
• wait 一直等到找到下一个严重的linux错误并重新启动系统或停电

迭戈说:

如果你等待其他答案解释,这将不会发生

即; 我上面描述的情况不可能发生.

迭戈是对的吗？

• 如果是这样,为什么我上面描述的情况不会发生？

或者迭戈不正确？

• 如果是这样,那么我今天晚些时候发布一个新问题......

补充说明

我发现这个问题可能会令人困惑,除非你知道PID是后台启动的PID过程.即;

my_function &
PID="$!"
PIDS+=($PID)

Answer 1

让我们来看看你的选择.

无条件等待所有后台工作

for i in 1 2 3 4 5; do
    cmd &
done
wait

这样做的好处很简单,但是你不能让机器忙碌.如果你想在旧工作完成后开始新工作,你就不能.在所有后台作业完成之前,您的机器得到的利用越来越少,此时您可以开始新的一批作业.

相关的是通过将多个参数传递给以下来等待作业子集的能力wait:

unrelated_job &
for i in 1 2 3 4 5; do
  cmd & pids+=($!)
done
wait "${pids[@]}"   # Does not wait for unrelated_job, though

等待任意顺序的单个作业

for i in 1 2 3 4 5; do
   cmd & pids+=($!)
done

for pid in "${pids[@]}"; do
   wait "$pid"
   # do something when a job completes
done

这有让工作完成后,你做的工作的好处,但仍然有就业问题,其他比$pid可能先完成,让你的机器得到充分利用,直到$pid实际完成.但是,您仍然可以获得每个单独作业的退出状态,即使它在您实际等待之前完成也是如此.

等待下一个工作完成(bash4.3或更高版本)

for i in 1 2 3 4 5; do
   cmd & pids+=($!)
done

for pid in "${pids[@]}"; do
   wait -n
   # do something when a job completes
done

在这里,你可以等到一个作业完成,这意味着你可以让你的机器尽可能忙.唯一的问题是,您不必知道哪个作业已完成,而不是使用jobs获取活动进程列表并将其与之进行比较pids.

其他选择？

通过自身的外壳是不是做的工作分配一个理想的平台,这就是为什么有设计用于管理批处理作业程序的众多:xargs,parallel,slurm,qsub,等.