The problem revealed: "There are two interesting side effects of SetCommMask and WaitCommEvent. First, if the communications port is open for nonoverlapped operation, WaitCommEvent will be blocked until an event occurs. If another thread calls SetCommMask to set a new event mask, that thread will be blocked on the call to SetCommMask. The reason is that the original call to WaitCommEvent in the first thread is still executing. The call to SetCommMask blocks the thread until the WaitCommEvent function returns in the first thread. This side effect is universal for ports open for nonoverlapped I/O. If a thread is blocked on any communications function and another thread calls a communications function, the second thread is blocked until the communications function returns in the first thread."
My code was obviously getting into the ReadFile function in one of the programs, but without timeouts in use, it stayed there forever, waiting for a byte to be sent from the other program using WriteFile, but this was blocked by the ReadFile on the other port.
I think this is a very subtly hidden bug, which is rather poorly highlighted in the documentation.
I have cured the problem by using ReadTotalTimeoutConstant to break out of ReadFile regularly, giving other threads and ports a chance to do something too.
I hope others may find this discovery useful.
