DragonFly users List (threaded) for 2006-07
Re: Asynchronous Console Messages?
: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!
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
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
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.