[fpc-devel] Threads and alot of crap continued
JeLlyFish.software at gmx.net
Thu Nov 9 08:43:49 CET 2006
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:
| await NEXT_TIME;
| emit EXPIRED;
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
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.
More information about the fpc-devel