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.