Re: some performance problems with async console client

[Niels Möller]

Marcus Brinkmann <marcus@gnu.org> 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