Re: some performance problems with async console client

[Marcus Brinkmann]

On Fri, Jun 14, 2002 at 10:10:05PM +0200, Niels Möller wrote:
> One way to organize the client may be as follows:

I pondered this today, and came to an almost identical model!  I am happy
to get this second opinion.
 
> 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".

> 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.

Actually, if you look at the code you will see that there is a
FILE_CHANGE_NULL notification that is always the first notification sent by
the server for synchronization.  So this is already the "poll" message. 
This way what you said in step two and three can look like this:

If the notification thread (well, ports_manage_multithreaded is still
necessary, as Mach doesn't let you receive messages in the order they were
sent easily) doesn't have enough room on the queue to add the notification,
it just deletes the queue, destroys the notification port, sleeps a bit,
creates a new notification port and sends it to the server with
file_notify_changes.  Then the server will automatically send the "poll"
(FILE_CHANGE_NULL) message, which will fit on the now empty queue.

Mmmh.  This requires a bit of experimenting.  I am not sure what would be
the best order:
1. delete the queue, destroy notify port, sleep, create new notify port
2. destroy notify port, wait until room is in the queue, create new notify port 

Number 1 has the problem that the notify thread could delete the poll
message immediately, if the update thread doesn't have a chance to run.  So
actually removing notifications from the queue seems to be suboptimal.
Something like number 2 seems to be more appropriate, and should lead to a
more fluent behaviour.

Thanks,
Marcus

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