manes@dasys1.UUCP (Steve Manes) (04/16/88)
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@magpie.MASA.COM