This is an exercise on the nuances in spawning processes and setting up pipes.
Overview: Two programs foo.c and bar.c are provided. Your job is to write your own program, bridge.c, that spawns them and sets them up for two-way communication by pipes. A makefile is provided for compiling all of them.
In more detail:
bridge should spawn both foo and bar as children, then wait for both to terminate.
foo expects two command line arguments for: file descriptor to read from, file descriptor to write to. See the sample foo.c for details.
bar expects two command line arguments for: file descriptor to read from, file descriptor to write to. See the sample bar.c for details.
So bridge should create two pipes: one for the foo->bar direction (foo writes,
bar reads), the other for the foo<-bar direction (foo reads, bar writes).
And bridge should exec foo and bar with arguments accordingly.
(snprintf() is very helpful for converting numbers to strings.
You may assume that each number is only 10 digits.)
bridge should not redirect stdout for foo and bar. They need stdout for the reports shown below.
For simplicity, please hardcode the pathnames ./foo and
./bar for the executables.
If bridge.c is correct, foo and bar will report these:
foo sends msg 1 bar reads, next line is what I get msg 1 bar sends reply 1 foo reads, next line is what I get reply 1 foo closes write end and waits for bar to do the same bar closes write end and waits for foo to do the same bar is satisfied foo is satisfied
The last two “satisfied” lines may be in the other order; this is up to the kernel.
A few common mistakes to watch out for:
exec(). There is diagnostic code in
foo.c and bar.c to help you cross check, currently disabled, but you can
enable and recompile.
When marking, I will use a different pair of foo.c and bar.c, which exchange some other messages and print some other reports. There is nothing to worry about if you do piping and spawning correctly.
What to hand in: bridge.c