In my suggestions at this node, I am assuming that the autoflush would have the same effect as manually flushing after your child's print statement. Further assumed is that this file event notification does work and means that the pipe is ready for reading. If the pipe has any data in it, then all of the data for a single msg should be coming forthwith and certainly fast enough to have no impact on GUI performance.

If both of those are true, then my suggested blocking read until DONE seen should work well and you don't need your read() statement. There should never be any "garbage" before the start of the frame, e.g. "MSG". Stopping reading after seeing DONE should leave the input pipe completely empty. Things are more complicated if 2 msgs could be "back to back". But since they are only sent once per 10 seconds, I see no problem. Of concern with "back to back" messages would be timing issues with "re-enabling" the file even notification mechanism - not sure how that would work.

A good assumption for these pipes is that they are lossless. Probability of corruption is on the order of a memory RAM error (which nowadays is very low).