Xenix Output Buffers

[Steve Manes]

Here's a problem I'm hoping some SCO wizard can shed some light upon.

Background: I ported a DOS BBS I wrote (Magpie) to Microport Unix and
then to Xenix this year.  One of Magpie's more appreciated features is
its speed and "hotkey" response.  With DOS, setting up such keys to
break out of message displays or to branch (immediately) to another
function is ho-hum stuff since polled input is so easy to do.  You can
support the same kind of inkey() type routines in *ix by opening another
handle on 'stdin' with NDELAY set and then checking for input
occasionally with read().  However, this method is unacceptable on
a multitasking/multiuser system, where repeated read() calls tend to
eat system performance like Fritos.

What I chose to do instead is attach Magpie's two main hotkeys (SPACE =
next message, TAB = abort display) to SIGINT and SIGQUIT, respectively,
and have those interrupts set flags for Magpie to deal with.  During
message display, Magpie is checking these flags constantly.  If a user
hits the spacebar during message display, the message will abort
immediately and the user will be moved to the next message in his read
path (which could be a message search, a thread read, a chronological
read...  unimportant here).  This works very well, except for one nasty
side-effect that I've found in Xenix (and not, surprisingly, Microport). 

When an interrupt is hit, Xenix flushes its output buffer.  However,
there is almost always some garbage spit out the comm port.  Sometimes
its a fragment of text from the buffer that SHOULD have been purged,
even if I use TCSETA to reset the terminal.  With TCSETAW, it's a large
block of coherent text that makes the hotkey real sluggish in
apparent response.

I can deal with this if I must.  But there's an additional problem.  When
Magpie returns to its main prompt (or branches to any general input prompt)
SPACE and TAB have to be unset via an ioctl() call otherwise getc()
would never be able to read a SPACE or TAB character.  This is where I'm
experiencing trouble.  If the buffer has not purged itself (despite the
explicit ioctl(TTYOUT, TCFLSH, TTYOUT) call when the interrupt is hit,
which should be unncessary if NOFLSH is unset), and an ioctl() call is then
made to unset the interrupt characters SPACE and TAB, Xenix will, about
every dozen such calls, get confused and trash part of the >next< buffer
it loads once the signals are enabled again.  Sometimes the trash is just
that; sometimes it looks as though Xenix loses touch with its own parity
and flips the high bits on for between 10 and 40 characters in the buffer.

Another problem: on some smart serial boards, like the ICC, TCFLSH seems
to have little or no effect.  This leads me to believe that Xenix
actually has two output buffers -- one a cache loaded by Xenix directly
and a second, smaller buffer tied to the IRQ line.  It seems as though
Xenix isn't doing a great job of managing the latter buffer and, of course,
the problem is aggravated by the speed of the remote modem.

Has anyone had any similar experiences with Xenix's serial output control
and have any tips to fix this problem?  I know... use TCSETAW, but
waiting for the buffer to purge before flushing and resetting the
terminal really ruins the whole feel and concept of "hotkeys".  Dumb
question: anyone have a PD serial driver for Xenix that I can play with?
-- 
+-----
+ Steve Manes
+ decvax!philabs!cmcl2!hombre!magpie!manes       Magpie BBS: 212-420-0527
+ SmartMail:  manes at magpie.MASA.COM