as the test sender, to generate coverage. There is little vetting done
here; any problems should be discovered by the verify scripts in ../src
at the time the code is pushed. This is simply a coverage test for sonar.
+
+
+Verification
+The unit and app test scripts pretty much verify sucessful runs. If it is
+necessary to see things like whether or not the "failure" of a pipe
+reader affects the listener (blocks it), then running the app test with
+-v and looking at the listener output will help. Lines like the following
+give clues about this:
+
+1616516620 [STAT] (mcl) mtype=0 total writes=1 total drops=0; during last 1s writes=0 drops=0
+1616516620 [STAT] (mcl) mtype=1 total writes=88 total drops=0; during last 1s writes=24 drops=0
+1616516620 [STAT] (mcl) mtype=2 total writes=88 total drops=0; during last 1s writes=24 drops=0
+1616516620 [STAT] (mcl) mtype=3 total writes=88 total drops=0; during last 1s writes=24 drops=0
+1616516620 [STAT] (mcl) mtype=4 total writes=88 total drops=0; during last 1s writes=24 drops=0
+1616516620 [STAT] (mcl) mtype=5 total writes=88 total drops=0; during last 1s writes=24 drops=0
+1616516620 [STAT] (mcl) mtype=6 total writes=10 total drops=78; during last 1s writes=0 drops=25
+1616516620 [STAT] (mcl) mtype=7 total writes=0 total drops=88; during last 1s writes=0 drops=25
+1616516620 [STAT] (mcl) mtype=8 total writes=0 total drops=88; during last 1s writes=0 drops=25
+
+The sender sends message types 0-8 inclusive, but there are only 7 listeners
+started (0-6) so we should never see successful wirte counts for types 7 and 8.
+Further, pipe reader for mt 6 stops early, and so we should see some drops after
+it has stopped; It stops after 10 successful reads, so the number of writes
+should be 10 or 11 depending on timing of the processes. There shouldn't be
+any drops on the other FIFOs.
+
+It is difficult, if not impossible, to test the logic that detects an
+interrupted write on the pipe to ensure that all data is written.