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. 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.
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.
No idea at all regarding fpGUI/X11 etc.
-Michael
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
