[fpc-devel] Threads and alot of crap continued

[Vinzent Hoefler]

On Wednesday 08 November 2006 16:08, Micha Nelissen wrote:
> Vinzent Hoefler wrote:
> > The answer to my "I always thought a timer is more comparable to an
> > interrupt or signal than a polling loop." was "That is a very
> > common misconception." which I still refuse as being a correct
> > answer.
>
> The irony is of course that you clamp to your interrupt definition,
> but still implement your log timed event with a loop :-).

Well, yes and no, just like I would do in Esterel, for example:

|loop
|   await NEXT_TIME;
|   emit EXPIRED;
|end loop;

Because I do not know of any other construct to express indefinite 
repeatition, I used a loop. Any other ideas? ;)

Yes, of course, this still *is* nothing more than an event loop, and its 
asynchronous character would only come from the fact that it is done in 
parallel with some main thread, so it neither does interfere with the 
execution of the main program nor does it depend on it.

> > Especially outside of the usual GUI-application, we seemed to be
> > talking about, because the user/programmer somehow has to make sure
> > that the polling is actually done some time in the future.
> > Considering that a simply "ReadLn" can block indefinitely already,
> > this is quite hard to accomplish then, isn't it?
>
> Well, readln is used in the trivial (T)UIs; TUIs/GUIs are usually
> event-driven,

Whatchamacallit, it was an example where calling this "event loop" might 
be close to impossible. Yet, admitted, the expiring timer still 
wouldn't stop the ReadLn from reading its file, so you're screwed 
either way, but you could for example emit a "beep" to the user from 
time to time. ;)

> like networked apps also can be. A Timer fits in a event-driven app
> just fine,

I didn't say, it doesn't, did I? If so, I'm sorry. But I even remember 
mentioning priority queues in that context (which could somehow ensure 
a timer event would be handled in time, so even "real time" is possible 
if enough care is taken by the programmer).

> and then a timer doesn't interrupt
> anything anymore; but your intuition may say that it should, that's
> why it's a common misconception.

Ok, I now understand where "my misconception" comes from. :P

We're back to the usual GUI application where everything depends on that 
event loop. :) Of course, that's fine for most "event-driven" 
applications, especially when being GUI. IOW, it can be considered the 
difference between being preemptive and being cooperative. ;)

Problem here is that I would call my event loop only every couple of 
hours, because responding to on the event "now process image data" 
takes so long. :) And as far as I understood, the problem was exactly 
that: To implement something like TTimer in an application which is 
*not* based on a regularly called event loop.


Vinzent.