严重Bug，任务调度存在问题，部分任务丢失。

[GeniusFunny]

例如：10个进程，50个任务，只完成44个任务；50个进程，50个任务，完成50个任务。
猜测是任务调度的时候出现了问题。

[GeniusFunny]

问题的原因：
当主控进程处于检测任务状态时，某工作进程处于空闲状态并将其复用，这是理想状态。
但是，如果该工作进程只是检测任务状态时处于空闲，而当我们将执行复用的操作时，该工作进程又变为忙碌状态，我们这个时候去复用，之前的分配给工作进程的任务就丢失了，所以存在部分任务丢失的情况。
更进一步，上述情况什么时候会出现呢？
首先，将工作进程标识为完成/未完成的操作是在工作进程处理的，主控进程只负责将任务调度给工作进程。
主控进程检查任务完成度时，检测到某一工作进程处于空闲，这个时候我们就会触发复用机制，这里其实有一个考虑，因为各个工作进程是独立的，如果又一个工作进程完成了任务，那么与这个工作进程在差不多的时间被分配任务的工作进程理论上有很大可能完成了任务，所以我们会再去检测所有工作进程的状态对所有的空闲进程发起一轮复用。
所以进程池的任务其实是一批一批的调度，这个怎么理解呢？给一群克隆的小学生布置作业，如果有一个完成了作业，我们完全可以考虑询问所有小学生是不是也完成了，然后给所有完成了作业的小学生发糖吃，而不是只给第一个完成的小学生发糖吃。
切回上述情况的探索，第一次复用不会出现异常，所以0-20是不会出现丢失的，但是以后的每次复用，例如任务18被工作进程8完成，这个时候IPC，检测所有的工作进程发现都完成了任务，这个时候触发复用操作，我们给进程0-9下发任务21-30，......内容暂定，尚未定位到具体的case

[GeniusFunny]

除了这个bug，也想到了一些其他问题，我们真的需要setInterval来去轮询任务状态吗？什么时候才需要轮询任务状态然后调度？
工作进程状态发生改变的时候，才是我们需要去检测任务状态和调度的时机。
工作进程完成任务/失败，我们是用IPC来通知主控进程的。
所以，显然，我们也可以利用IPC来通知主控进程进行检测任务状态和调度。
之前说的肯定有更好的办法来取代setInterval轮询，是的，这个就是更好的方法
当然，还有更好的方法