
|
[haiku-appserver]
||
[Date Prev]
[10-2005 Date Index]
[Date Next]
||
[Thread Prev]
[10-2005 Thread Index]
[Thread Next]
[haiku-appserver] Re: Scrolling (was Re: breakthrough)
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Sun, 23 Oct 2005 14:06:32 +0200 CEST
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 :)
To make 2) work at least a bit efficient, a port with a flexible queue
would need to provide a buffer (in userland) that could be filled when
kernel space becomes tight. Obviously, such a mechanism couldn't even
guaranty that a message can be delivered to a port, so I'm not sure if
it helps that much (or just wastes some memory).
Basically, when a thread is scheduled, it would have a look if one of
its ports have a message count above a certain watermark, and if that's
the case, it would empty the queue into the provided userland buffer.
Of course, that would only work with small messages, and could have
some minor drawbacks on SMP machines as well.
Bye,
Axel.
|

|