Console input line redraw problems + fixes (v2)

Project:	JNode Core
Component:	Code
Category:	bug report
Priority:	normal
Assigned:	Unassigned
Status:	closed

When the user enters a key, the ensuing screen refresh is very visible.
The refresh repaints the entire line, including the prompt. Unfortunately the prompt is repainted using the current color of the console outputs stream; typically white. This is obvious in 'js', where the prompt was originally output (in red) by the console's error stream.

This addresses both of these problems, by making the cursor invisible while the line is repainted, and by not repainting the prompt.

In addition, there is a small change to org.jnode.driver.console.textscreen.TextScreenConsole to reduce the number of calls to syncScreen which appears to be rather expensive (at least in the case of the PC Console driver).

I also noticed that the console implementation is not thread safe. There is lots of potential for problems if two or more threads are reading from or writing to the console at the same time.

Finally, I noticed that org.jnode.driver.console.textscreen.Line has some problems if the input buffer contains literal TAB, BS or NL characters. The Line class is unaware that these characters don't occupy just 1 character position on the screen.

Attachment	Size
issues_50	8.57 KB

I've tried your patch.

Submitted by lsantha on Fri, 08/10/2007 - 20:34.

A strange pattern has appeared in the behaviour of the console.
When the current line is on the bottom of the screen and you start typing a new command the screen scrolls upwards one line. Originally it only scrolls upwards on new line, that is the ENTER key. This is a regression that I cannot let into the source. Could you fix it please?

I'm aware of the threadsafety issue of the console, it shows up during boot too sometimes where message bodies get interleaved. We should try to fix this, but we should look out to deadlocks I'm affraid.

I have noticed an other problem too. You can reproduce it by:
- freshly starting jnode
- open a second console
- start js in it and immediately switch back to the first console (boot console) while the js startup is still in progress
- in the boot console wait until js has started up. You can tell when that happens because the output of js will appear in the boot console.
The result is that js is getting the input from the second console and sending the output to the boot console.
I've observed the inversed situation too (when the boot console provides the input for js which is running and sending its output to the other console) but I don't have an exact scenario for reproducing it. This appears to be a threadsafety issue too.

Regards, Levente

Thanks for your testing ...

Submitted by Stephen Crawley on Sat, 08/11/2007 - 03:30.

I'll look into these problems.

Root cause of the output misdirection behavior.

Submitted by Stephen Crawley on Sun, 08/12/2007 - 00:51.

Actually, I suspect that some of the output misdirection problems are due (in part) to the fact that System.out is being switched all the time.

For example, it is changed (globally!) whenever a new application is launched and whenever the user switches consoles. An application that uses System.{out,err} may end up writing to the wrong place (console or file).

The only possible fixes for this are:

have the affected applications cache System.{out,err} before the streams get changed out from under it,
running applications in isolates, or
setting up System.{out,err} as proxies that dispatch to thread-specific (or proclet specific) streams.

In fact, the first option above is impractical for the following reasons:

The first time an application is launched, there is a significant delay (while the app is compiled) before any code is executed. If the user switches consoles in that time window, the application will end up caching the wrong streams.
We don't want to have to change third-part Java applications to get them to run on JNode just because they use System.{out,err}.

So that leaves us with isolates and proxied System.{out,err} streams as the only options.

#1

Submitted by Stephen Crawley on Sun, 08/12/2007 - 00:09.

Status:

active

» closed

Here's an updated version of the patch that addresses the regression that Levente found.

It also fixes another (obscure) bug that I noticed. If you try to enter an input line greater than 80 * 24 - 'prompt width' characters, then tried to move the input cursor back to the start of the line, the part of the line with the cursor in it would be off screen. I'm pretty sure this is a long-standing bug.