On 17.12.2009 11:46, Ingo Weinhold wrote:
In Haiku notifications don't start arriving until the first window is finished (exits MessageReceived()) and then the pending Node Monitor notifications flood the second window. Why are not Node Monitor changes immediately dispatched to watchers - handlers that issued start_watching()?They actually are, or at least should be. One thing Haiku does differently from BeOS is that the kernel no longer sends node monitoring directly to the watchers. Because it couldn't wait writing to a port, it had to drop messages, if the target port was full. In Haiku node monitoring messages are sent do the registrar, which relays them to the watchers. If a port is full, the message is queued and tried to be delivered later. Messages will be dropped eventually, too, but only after a very generous memory limit has been reached. So as long as a looper only temporary fails to keep up with its messages, one should never experience dropped messages.
Thanks for the explanation! It's ok - it is simply a matter of different notification rates.On my Haiku setup a writer thread is simply able to update more attributes between two notifications to the watcher. In fact, often the writer completes its entire batch of a couple dozen files before the watcher even gets the first notification.
That's why I thought the writer needed to finish first - nothing to do with it really ;)
Additionally, my app does some relatively heavy content processing on every modification notification so setting my watcher thread to B_NORMAL_PRIORITY (it was LOW_PRIORITY before) actually made notifications a bit more lively - but still far from R5, though.
But that is just my system. YMMV. It seems pointless to run test cases on different machine setups - the Node Monitor does work ;)
Tnx Bye, MK