In my experience, it is better for the parent process to be, basically, a supervisor, not “an active player in the game.”

In other words, in your scenario I would have two child processes:   the one that you describe, and a second one to “perform some action.”   The parent, then, sits in a wait-state, biding its time until one of the two of them finishes their task.   The child processes, having signaled their parent, then enter a wait-state asking for further instructions.   (Queues are a great way to handle this sort of thing.)

If the “perform some action” action needs to be suspended when the first process has completed its work, then of course the parent could signal that child to do so.   But it may well be that the work of the second process could continue, perhaps at a much lower execution priority.   The operating system could be relied-upon to fairly distribute the available CPU(s) time among the three of them, giving you a very flexible and robust arrangement.

It is also frequently useful to devise a queue-based mechanism (hint:   there are many CPAN modules already out there for this...) which would allow you to express things like “download a file” as “create a ‘download a file’ request and place it on such-and-such a queue.”   This queue is then serviced by a pool of n “worker bee” processes or threads, all under the supervision of a parent.   The workload-level that the CPU(s) undertake is strictly governed by the size of that worker-bee pool.   (The queue, on the other hand, can become as large as it likes... or not... your option.)

Again:   “do not do a thing already done!”   This is “a legendary architecture,” and there is plenty of well-rounded CPAN support for it.