i could use some feedback on break sequences

i've finally added delays to break sequences in hopes that sun alt-break
and LOM interactions would work more reliably.  i'd like to insert
proper delays into the pre-defined break sequences, but i'm not sure if
they're really necessary or where they should go.

so, here are my thoughts about alt-break.  i've seen references (to
older 2.6/2.7 patches, i believe) that state you need a 0.5 second delay
between characters in the '\r~^b' alt-break sequences (using no more
than 5 seconds).  i've also see references (solaris 8/9) that state you
shouldn't run binary protocols over the serial port with the alt-break
enabled as it could be interpreted as the break sequences.  so, it leads
me to believe they removed the requirement for a 0.5 second delay
between characters.  i'm tempted to insert the delays to be backward
compatible with the 2.6/2.7 patches...but if anyone can verify that the
delays aren't necessary (or definitely are), i'd love to know it.

as for the LOM interaction, there is currently a '#.reset -x\r'
pre-defined.  should there be a delay between the '#.' and the 'reset'?
from the very little i remember, there is a pause and i think a
potential for data loss if the 'reset' comes too quickly.  but, again, i
can't verify it.  i figured giving the LOM a chance to break out and
produce a prompt would be a good thing.  can someone with a LOM-based
machine provide experiences with it?

i've looked back at the mailing list archives and seen references to
folks having trouble with things and needing delays.  i just wanted to
get the hard specifics on placement so the defaults could be improved.
please send all your feedback directly to me instead of the list.  if
you feel you have something useful for everyone, then yes, share with
the list, but stuff like "works for me" or "i vote for the delay here"
should really just come to me.

for those still with me, the delay is triggered with at '\d' spec in the
break sequence and it causes a 0.33 second sleep.  yes, that sleep puts
the entire process on hold for 0.33 seconds, but the cool thing is if
you do '\d\d\d' in the sequence, client and console data is checked and
processed between the 0.33 second delays, so you can't really hurt the
server too badly by stacking up the delays (a serial break [\z] can
cause a delay too, and it is handled the same way).  why 0.33 seconds?
just seemed like a long enough time to be useful and short enough not to
cause excessive delay.

thanks much folks.  8.0.0-beta4 should be pretty cool.  ;-)

Bryan