Hi, I just added the seqno serialization in the console client, and noticed that there is a severe performance problem. The issue is that the console server is rocking fast, and the client can not keep up with this speed in updating the display. Take a "find /share > term" command. It will write the data in large chunks (don't know how large, but larger than 256), which will be split up into 256 bytes blocks, and each of this blocks usually would generate three update notifications for each client. So the number of RPCs from the server to the client is a multitude of the RPCs from the terminal to the console server. This results into a massive thread explosion in the client similar to the pageout thread explosion.
The next step to solve this will be to cut down the number of RPCs. I will try to send only three rpcs for each write to the console (rather than each 256 bytes block). The three rpcs are: writes done, scrolling done, cursor position. By rearranging the fields in the file, I can group the scrolling and cursor position into one RPC. However, as now the scrolling done can be larger than the screen itself, I need to change the semantics of cur_line, which will be incremented only as long as uint32_t doesn't overflow (this is important, because otherwise if it changes from 1 to 2, the client doesn't know if it actually grew from 1 to nlines + 2). However, this will still result into two RPCs per write. I am not very confident that this will eliminate the problem, as the client will always be slower than the server. One cheap way out is to make update notifications synchronous, so the server will become much slower, but screen updates will be synchronous. Maybe for a first version this is good enough. Another way to improve the situation is to make reception of update notifications and the actual screen updates asynchronous in the client, too. This requires a bit more logic, but adds flexibility in that the client can notice if a lot of output appears, and change the way it updates the screen to a more polling-like mode in this case. All of this is possible, and I don't know what is best. It is likely that I change it to be synchronous soon, as this is the simplest solution and should work acceptably for now. It would be a compromise between having everything in one program and being fully asynchronous (which Roland rightly pointed out to be more ambitious). Thanks, Marcus _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
