On Thu, 5 Apr 2012, Michael Schnell wrote:
On 04/05/2012 03:39 PM, Michael Van Canneyt wrote:
Events do not automagically appear in your application, even under windows.
They are not interrupts.
AFAIK, in Windows, the Application main thread can call an API function to
wait for the next message.
Exactly. That is called 'polling' windows...
Here it uses no CPU cycles and when a message in
the queue for that thread arrives from what origin ever, the thread is
activated at once and will run according to it's priority thus minimizing the
latency to the limit that the OS and the other running tasks allow. I don't
see why a "timeout" would necessarily be enabled to return from that call
(providing real polling), as there should be no notifications to the main
thread that don’t run through the queue, generating such a message and waking
the Main Thread.
Of course if the main thread is just working on an event, when a new event is
fed to the queue, it will first finish its current work (unless it explicitly
calls "Application.ProcessMessages") before it is ready to handle the new
event. But this is just how a single-threaded application needs to work.
I would not call this "polling", as the "main Loop" only runs at max a single
turn for each event, while the process sleeps until the next event arises.
You have a strange definition of polling.
Polling = Checking something at regular intervals.
No more, no less.
Whether or not the CPU is used a lot, or how many threads are in the
application, is irrelevant for the definition, they are implementation
details.
Maybe GTK does not allow for such a design, though, because not all events
can be run though a single queue with embedded waiting/waking functionality.
Qt/GTK/X11 allow for this design as well.
Michael.
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
