[fpc-devel] Threads and alot of crap continued
JeLlyFish.software at gmx.net
Wed Nov 8 16:31:02 CET 2006
On Wednesday 08 November 2006 14:43, Micha Nelissen wrote:
> Vinzent Hoefler wrote:
> >> but it's not realtime by any definition.
> > First, I never said "real-time" in that context and second: it sure
> > can
> I concluded that from your quote:
> Timing events allow for a handler to be executed at a future point in
> time in an efficient way, as it is a standalone timer that is
> executed directly in the context of the interrupt handler (it does
> not need a server task).
I mainly quoted that to clarify my intention of the term "timer",
because there seemed to be some confusion about that.
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.
[It seems that a lot of people seem to put all their efforts in looking
at a single particular implementation before trying to see the big
I didn't say that it *is* necessarily an interrupt or signal, I just
said it is comparable to one, by which I meant its preemption of
To implement the semantics of "timing events allow for a handler to be
executed at a future point" a polling-loop could prove to be a very
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?
> I read server task as thread, and a timer as interrupting any thread
> at the time it was fired and calling some callback then.
Yes. And if a timer implemented as thread has the highest priority it
would even do exactly that, and I also said that in one of my last
mails. Still no word of "real-time", although now we're catching up. ;)
> Maybe Ada creates a hidden thread itself in which it calls these
> callbacks (so cheating on its own definition IMHO),
Maybe. :) I didn't read the new standard yet, but I guess, the actual
implementation is left to the implementor as long as the required
semantics are kept. Although it seems rather unliky it actually might
be an additional thread on top of the OS' scheduling system, or it
might be a real hardware interrupt, or it might be the scheduler of the
runtime without any OS running at all ...
> but otherwise the
> only value for such interrupts would be realtime requirements.
Well, Ada is - of course - a language designed with real-time systems in
mind. Yet, this doesn't mean, that the general concept is useless
outside of a hard real-time scope.
Considering that in the GUI-application such things seem to be used very
commonly (due to the polling-loop implementation without the
implications of being executed concurrently), the value seems to be a
little bit greater than to "useful in real time environments only".
As far as I understood, the only problem here we discussed were
applications without such dedicated event loop.
> > microseconds running on an RTOS, of course.
> That's not the common OS case.
Precisely, and that's why I even tried to avoid the term "real time"
thus far. Yet, such feature can be useful.
More information about the fpc-devel