"Martin James" <mjames_falcon@dial.pipex.com> wrote in message
news:44a0d10c$1@newsgroups.borland.com...
> After the main thread has handled the 100 objects from the thread-safe
> queue, it then gets 99 PostMessages and polls the empty queue 99
> times for nothing. So, for the thread-safe queue, no saving on handling
> PostMessage receipts, extra code to be run in popping the queue plus
> an extra CS acquire/release for each queue check :(
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.
> There is a persistent rumour that Windows occasionally loses messages.
All the more reason not to rely on messages when possible.
> 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, 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.
> 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.
> 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.
Gambit
