That is easy enough to handle, though. After processing the first message,
you can purge the message queue of those other 99 pending messages that
won't have any effect since their data was already processed. That way, you
are only entering the thread-safe queue once.
Yes, that's true, but then the Windows Message queue has to be purged of the
99 unwanted notifications.
AFAIK, a WMQ cannot be purged except by a GetMessage/PeekMessage loop.
Since your custom messages in the queue are mixed-in with other OS and other
custom messages, the loop would have to get/peek messages and check each one
to see if it is one that should be purged, keeping a count of 'real' custom
messages that have been dumped, until th ecount reaches 99. If a peeked
message is not a custom message, it would have to be dispatched in the
normal way. This is just like the normal message-processing loop, so no
advantage gained there.
> > There is a persistent rumour that Windows occasionally loses messages.
>
> All the more reason not to rely on messages when possible.
The OS survival depends upon queued messages being delivered without loss.
> > I think that this fallacy arises from the behaviour of timers, which
> > the Windows docs imply work by *queueing* messages.
>
> A message queue can only hold so many messages at one time,
10000
> and there are
> thousands of messages flying around the OS every second. So yes, it is
> possible for messages to get lost if a queue fills up due to slow
> processing.
This will happen only under extreme circumstances, eg. a runaway poster.
The OS cannot lose messages under any remotely normal operation and remain
intact - it just must not, cannot.
I agree that it behoves the developer to try and ensure that custom
inter-thread messages are throttled-back under sustained overload, both to
prevent excess memory use with thousands of objects queued up and to prevent
PostMessage failures at 10000 entries.
> > If the main thread is tied up for a time longer than a timer interval,
> > it appears that a *timer message gets lost', hence the erroneous
> > extrapolation that all windows messages are at risk of occasional
> > 'loss'.
>
> They are at risk, although it is rare. I have seen it happen before.
I have never seen it happen. After weeks of soak-testing, apps based on
messages do not lose a single object, (well once the Martin-induced bugs
have been removed:). An OS queue losing messages that have been
successfully posted in any circumstances is a disaster, a catastrophe, for
the OS.
> > Why Borland was so concerned over lifetime-management of one
> > window is beyond me - I would create the thing anyway at app. startup,
> > whether TThread was used or not, and just leave it there.
>
> That would be a waste of resources. A *LOT* of VCL resources are
> reference-counted internally to minimize resource usage.
One window per app? I think the OS will not miss such a resource.
Rgds,
Martin
