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. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
