Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.sys.att,comp.bugs.sys5
Subject: Re: bug in 3b2 console driver?
Message-ID: <5792@brl-smoke.ARPA>
Date: Sat, 25-Apr-87 18:52:34 EDT
Article-I.D.: brl-smok.5792
Posted: Sat Apr 25 18:52:34 1987
Date-Received: Sun, 26-Apr-87 21:54:14 EDT
References: <681@mrstve.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 20
Xref: mnetor comp.sys.att:368 comp.bugs.sys5:111

In article <681@mrstve.UUCP> rjk@mrstve.UUCP (Richard Kuhns) writes:
>printf("message, no newline");
>fflush(stdout);
>which seems to work perfectly on anything except the console.
>It works perfectly (so far) on the console if I add
>ioctl(fileno(stdout), TCSBRK, 1); /* wait for output to drain */
>after the fflush().  Has anyone seen this before?  As in, is it a 3b2
>problem or System 5 problem?

The only thing printf and fflush do is a series of
write(2) system calls to put characters into the kernel
character queue for the device.  Without the fflush the
characters would remain buffered in the user space until
a newline were output.  Write(2) is too generic to blame
for this kind of problem.

It sounds to me like a problem with the Scheme software.
My guess is that a subsequent ioctl() is doing a TCSETA
instead of a TCSETAW; this can cause pending output to
be mangled or discarded.