Marcus Brinkmann <[EMAIL PROTECTED]> 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 _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
