Asynchronous Console Messages?

[Matthew Dillon]

:Hi everyone,
:
:I've always been a little curious about the way the typical unix
:console works.  Why is it that applications must wait for text to be
:displayed on the console before continuing operation?  Shouldn't these
:messages merely enter into a queue to be displayed whenever the system
:can get to them instead of slowing things down to the maximum speed
:they can be output?
:
:Perhaps I'm mistaken about this issue :) -- and I'm certain that if
:I'm not there's a reason for it working the way it does.  I wouldn't
:mind knowing the reason, though!
:
:Best Regards,
:Ben Cadieux

    Well, any console I/O from user processes will be buffered just like
    normal tty I/O, but a tty buffer is fairly small (e.g. 256 bytes
    or so).  However, the actual interaction with the console device
    is going to depend heavily on whether the console is video or a 
    serial port.

    A video console isn't actually an I/O device in that the cpu can't
    just queue data to it and have some piece of hardware handle the
    actual writing out to the console.  The kernel has to write the data
    directly into video memory.  Since the video memory on a PC is
    typically mapped either through the internal (and very slow) ISA bridge
    or via the PCI bus, writing to it is not as fast as writing to normal
    memory.  Performance isn't terrible, though, since the kernel
    typically maps the memory with hardware caching enabled on the video
    mapped pages.

    A serial console is an I/O device and a standard user program writing
    to it will buffer just as it would to a normal serial port.  The
    program will stall only if the buffer fills up.

    printf()'s made by the kernel are going to be synchronous no matter what
    because the console has to be able to handle the printf() being
    called from anywhere, including interrupt code.  This can result in
    a serious slow down especially over a serial console but I don't see
    that we have much of a choice in the matter because vital information
    can be lost (e.g. just prior to a crash) if it isn't synchronous.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>