[fpc-devel] Threads and alot of crap continued

[Vinzent Hoefler]

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:
>
> <meta-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).
> </meta-quote>

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 
picture. ;)]

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 
ongoing operations.

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 
problematic solution.
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.


Vinzent.