bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: improved console interface (was: Re: some console code checked in


From: Marcus Brinkmann
Subject: Re: improved console interface (was: Re: some console code checked in
Date: Tue, 23 Apr 2002 15:26:06 +0200
User-agent: Mutt/1.3.28i

On Tue, Apr 23, 2002 at 02:18:33AM +0200, Marcus Brinkmann wrote:
> There are probably more points that I forgot now,

Yeah, I have two more.

When having character data and attribute data not interleaved, you have an
ugly race condition that can lead to an update of the attributes but not the
text or the other way round.  So for a small amount of time the wrong
attributes might be used for a text (unless we either make it the convention
that notification messages for text imply change of the attributes, or we
span the whole region between the text and the attribute and declare it as
changed, which is inacceptable).  OTOH, if the attributes and text are
interleaved, you can not update just the text and leave the attributes
intact without update (so you might or might not lose some performance this
way).

There is another race like this with asynchronous update messages.  Consider
that the text ABCDE is written to the screen, and then the text 12345 is
written just over that.  While the display driver processes the first
notification, it reads out the mmap'ed buffer and might read ABC45, if the
change in the virtual screen is performed after it has read the C.
Of course, with the next notification message, it will process this region
again, and will write 12345.

Ok, I am scrutinizing the standard issues for asynchronous screen updates. 
Maybe the times that such incorrect renderings occure are too small to even
worry about it.  However, I think it is good to know what we are talking
about.  Some of this could be fixed by synchronizing the virtual screen with
the display driver, but this is probably inacceptable performance-wise.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org address@hidden
Marcus Brinkmann              GNU    http://www.gnu.org    address@hidden
address@hidden
http://www.marcus-brinkmann.de



reply via email to

[Prev in Thread] Current Thread [Next in Thread]