Marco, I see you had a StackOverflow question on this a year or so ago. Did you ever get anywhere with it in practice?

I'm about to hack a SerBreak() into my re-implementation of serial.pp, and since I have dedicated HP comms test gear here I could check that it was interleaving with dataflow correctly.

In our previous episode, Mark Morgan Lloyd said:

Marco, I see you had a StackOverflow question on this a year or so ago. Did you ever get anywhere with it in practice?

It was an idea to lower the overhead and improve the reliability of our serial protocol. (because of the out of band information is guaranteed unique and can't happen in the datastream)

But if you can't insert the break cleanly into the character stream, it is useless for protocol purposes I guess. And it was not worth centering the rest of the application around it.

I did't have any confidence in the solutions presented (just reset the connection and pauze) because both the pauze is not reliable in length on preemptive systems like Windows, and the damage to the FIFOs is a problem, since that would negate the size advantages.

I never pursued it further.

OK. I'll start off with the standard API, with an explicit check that the output has drained by default, and a mSec parameter (which will get rounded up to something gross on unix).

I'm still hoping that at some point the units and test code will be bundled in place of the existing unix-only serial.pp.

I've added it, but it's best avoided except for the classic use of getting a remote system's attention. On Linux the only working parameter is zero indicating a break of around 250 mSec, on Solaris it doesn't work at all, and on Windows I've not found a way of preventing a break from trashing anything that's sitting in the Tx buffer.

Modified library appended to issue 18946 in Mantis.