Marcus Brinkmann <[EMAIL PROTECTED]> writes: > 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.
One way to organize the client may be as follows: First step: Have a separate thread that receives the notification messages, and just write them onto a queue. Have a different thread read the queue and do updates to the screen. So far, there's no real improvement, the main point is that you can easily examine the length of the queue. Second step: Let the notification thread check the length of the queue, if it is larger than some constant (say, 17 pending updates), empty the queue, and add a single entry that says "please poll". When the thread that reads the queue encounters the "poll" entry, it should to a complete update, first reading the current meta information (scroll position, cursor), and then read the entire screen rectangle and draw it. As a third step, one might also decrease the number of rpc:s as follows: Before the notification thread writes "poll", it cancels the notification request on the file. When the update thread reads the "poll" element, it should do three things, in order: (i) sleep a short while, so that it doesn't consume 100% cpu, (ii) reenable notifications on the file, and (iii) finally redraw the entire screen. Regards, /Niels _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
