Noame:

If I'm interpreting your question correctly, then you're wanting P1 and P2 to work something like this:

P1 [A------B-------C--------D-------E]
P2         [1-----2--------3]

A: P1 starts working
B: User wants a report, so P1 spawns job P2.  P1 now waits.....
C: P1 detects that the .TXT file is ready, so it resumes working
D: P1 detects that the .XLS file is ready, so it reports "succeeded"
E: P1 ends

1: P2 starts and begins work on the .TXT report
2: P2 finishes the .TXT report and begins work on the .XLS report
3: P2 completes the .XLS report and ends.
[download]

So your first task is to figure out how to communicate between your processes, and what messages you need to communicate. For your task, you could get by with three messages, all from P2 to P1. The first message would be something like "The text file is ready", the second message would be "the excel file is ready", and the last message would be "Error!"

Now how to perform the communications? While there are packages available for interprocess communications, I wouldn't use them for this job. Instead, I'd use indirect communications by having P2 create explicit clues. For example, when the text file is complete, the file "REPORT.TXT" would appear in the output directory. When the excel file is complete, then "REPORT.XLS" would appear in the output directory. If P2 wants to report an error, then "REPORT.FAILED" would appear in the output directory.

Hopefully, you already know how to perform task P2, so we'll skip that.

Next, you need to figure out how to receive the messages from P1. Luckily, perl provides -e to detect the existence of a file, so you can use it to look for your three messages. So P1 will spawn P2 and wait for REPORT.TXT or REPORT.FAILED to appear. If REPORT.TXT appears, then it can continue some operation until REPORT.XLS or REPORT.FAILED appears.

Finally, you need to figure out what error handling you need. So, what errors would you expect to see? P2 could hang forever, never generating any messages. P2 could fail after generating the text file never creating REPORT.XLS or REPORT.FAILED. So think of all the basic scenarios. For each of the error cases you can think of, figure out how to detect it, and how to correct it. Note: You need to think of all sorts of oddball cases, such as: What happens if P1 crashes, and you restart it when P2 is running? How are you going to handle it when the new P1 starts a P2 job and you now have two P2 jobs running? There can be many potential error cases, so be sure to stretch your imagination here. (As you're laying out your code blocks, think of what assumptions you're making, and what could fail for the operations you're performing. That will help you find many of your error cases.)

Now that you know the messages, interactions, and what sorts of error handling is required, lay out your code blocks, write 'em and test 'em.

...roboticus