Re: some performance problems with async console client

[Niels Möller]

Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:

> (well, ports_manage_multithreaded is still necessary, as Mach
> doesn't let you receive messages in the order they were sent easily)

Huh, that sounds hairy and suboptimal. For instance, I'd expect that
if a thread of mine sends some asyncronous and overlapping write
request to a file server, they will be processed in the order I sent
them. Does mach require the *client* thread to serialize the requests?

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

When this case happens, I'd expect the information in the queue is
obsolete, or at least obsoleted very soon, so it seems a little
useless to do the corresponding updates. So I think 1 makes sense. On
the other hand, 2 will probably look prettier, at the cost of some
more cpu cycles; to me it seems like (2) will make the client never¹
sleep at all during heavy screen activity.

Yet another altarnative may be:

3. Delete queue, destroy port, artificially add a FILE_CHANGE_NULL to
   the queue, then wait until the update thread have processed that
   update (which is some time after the queue is emptied), perhaps
   sleep some more, then create a new notify port (which will result
   in a new FILE_CHANGE_NULL added to the queue, followed by more
   updates). 

The nice thing about (3) is that the update pause happens between two
complete (poll-like) updates.

¹ Actually, it will sleep a moment when waiting for the first
  notification message after creation of the new port, but that's
  almost not at all.

Regards,
/Niels