More couples of cents thrown in from here: >> why would you loose BMessages ?? (and how ?) >> never had any problem with them... maybe you mean 'corrupt' ? > >It is for instance a known problem, that, when the machine is under load, Because load could make some threads less responsive and make them not keep up with messages they receive, yes.. >sometimes B_MOUSE_MOVED messages (in particular with B_EXITED_TRANSIT) got >lost... Not sure what you refer to here; it can't be the bug that one can e.g. see in Postmaster when the cursor changes to an arrow because of a "mouse over" and then never changes back to the hand, because that one happens regardless of the load, and seems very much to be a bug in the app_server -- people may reproduce it at will by "incorrectly" MoveBy()ing their BViews, having a child clipped by its parent for example.. it struck me a few weeks ago. Maybe you meant this as a subset of the previous point and I'm going over the top for nothing, sorry :-) > which causes some pain, if your favorite view relies on them. Anyway, AFAIC not much has evolved since this topic seriously arose on "os news" some time ago, I've only had the experience of a bug triggered by a thread in one of my apps being blocked (or too slow) at processing messages and thus reaching the maximum limit set in the constructor before dropping those that are above that limit (which is the desirable behaviour of course). So my status/take has become: * number of messages dropped overall: some (indeed it may happen.. have to bite the bullet here). * number of messages dropped that I'd wish were not: 0. The only thing I'd claim "could be improved" in 5.0.3's design about this is, one should be able to get a notification that messages were dropped, to be able to kill the application altogether or maybe something smarter; having hunted for a phantom bug for 2 hours before understanding what was going on was no fun, as I recall :-) -- http://cdegea.free.fr/ | BeDev E-16870 "What's oil got to do, got to do with it" -- F02 Chorus