[Lazarus] Strange dependency of units

[Michael Schnell]

On 04/05/2012 05:36 PM, michael.vancanneyt at wisa.be wrote:
>
> Then try this:
>
> Polling = Asking or checking something.
OK, if you want it that way, I'm with you now.
>
> This is as opposed to 'interrupts', where you're not asking, but where 
> the
> environment interrupts whatever you're doing and forces you to handle the
> event right there and then.
Interrupts are no issue here. That is a completely different concept.

Maybe the distinction I have in mind might better denoted as "busy loop" 
vs. "sleep until action is necessary".


> The 'regular intervals' you seem to insist on, 
Sorry but this was your wording I seemingly misunderstood.

> means you just put a timeout on the
> time you wait for your answer when polling.
>
>>> Qt/GTK/X11 allow for this design as well.
>>
>
> Just add a file descriptor to the main loop mechanism, and write 
> something to it
> from wherever you want to send an event.

Does GTK know files ?

Of course, if there is no GUI, you will use such OS API based Sync 
mechanisms to do a non-busy wait (there are lots more such as Pipes, 
Semaphores, Mutex, ...) . But if there are GUI (here GTK) events to be 
handled _and_ user (e.g. Thread-) originated events, you need to decide 
where to sleep. If sleeping in a GTK call, the "file" events will not 
wake up the thread;  if waiting for a file, the GTK events will not wake 
up the thread.

So I see two solutions:

(1) Wait in one environment (e.g. GTK) and define the wait with a 
timeout specification. (I suppose that this is what the GTK Widget Type 
does. ) This implements a (partly / regular interval) busy loop polling 
for the other (e.g. Thread- originated) events.

(2) use an additional thread that waits for the GUI events in an 
appropriate API call and use same to transfer the events to the non-busy 
waiting Main loop. I understand that this is (a) rather complex and (b) 
uses up some performance when handling GUI events. But in fact this will 
reduce overall CPU time and the latency of non-GUI events.

So I do understand that the LCL does not implement something like (2) 
for good reasons.

Theses thoughts might show why I recon that the LCL does "busy loop" - 
polling in GTK but not (necessarily) in Windows.

Thanks for your time.
-Michael