On 2005-10-23 at 14:06:32 [+0200], Axel Dörfler wrote:
Adi Oanca <adioanca@xxxxxxxxxxxxxx> wrote:
But related to this I think we have another problem: Messages being dropped when client's queue is full. This is a very serious problem! We didn't thought the app_server with this aspect in mid. If an _UPDATE_ message is dropped, we are in big trouble.
This isn't a new problem, though, we share this problem with BeOS as well. There are two ways to fix this problem: 1) have a better delivery mechanism, like what we do with the node monitor for Haiku 2) have ports that allow for a more flexible queue - that would need to be solved at kernel level, and I think was one of Michael Phipps preferred topics :)
IMHO, trying to deliver all messages is not the best approach for the app server. If a window is so busy, that it can't even keep its looper port empty, one should definitely not try to send it all B_MOUSE_MOVED messages. I think on the app server side there should be a per window queue of outgoing messages that could not be delivered without timeout. The queue would store additional information that allow it to drop B_MOUSE_MOVED messages and compact _UPDATE_ messages.
The messages in the queues would periodically be tried to be sent, either by a dedicated thread doing that for all windows (similar to the MessageDeliverer implemented in the registrar) or maybe by the per window app server threads.
That's a good idea. Maybe picasso thread could be used for that too.
BTW, since the number of messages in the looper port is actually no indicator of how busy the window thread is at the moment (only how busy it was since it last transferred the messages from the port to its message queue), it might be a good idea to let the app server know the number of messages in the queue (e.g. through shared memory), so that the server-side queue could also be used when the port is not full but there are too many messages in the client side message queue already.
Thanks for your input Ingo!