[fpc-devel] Threads and alot of crap continued
mschnell at lumino.de
Wed Nov 8 10:33:01 CET 2006
Vinzent Hoefler wrote:
> On Tuesday 07 November 2006 17:10, Michael Schnell wrote:
>>> Of course, because the common concept of a timer is as asynchronous
>>> as in "multi-threaded" or even "interrupt".
>> That is not true ! (See my other post.)
> Well, a timer is, even though the Delphi implementation of a so-called
> TTimer object might not.
A TTimer by definition is what a Delphi TTimer is (and of course the
Lazarus implementation is done according these lines).
Of course you can do a TVinzentTimer that does a callback in a thread.
In Linux this even is a very useful thing in some projects, as (other
than in Windows) creating threads is very cheap here. The user needs to
be aware of what he is doing and that hes required to protect resources
from mutual access and that it's not possible to uses LCL functions
(many of which are not thread save) in a TVinzentTimer event.
> Basically a timer starts, later then it expires an that expiration
> creates an event (in the old days we called that interrupt). This event
> is no way synchronous to the code currently running.
As said, his is useful in some projects, but by far more difficult to
use than the Delphi-like TTimer.
>> Timer events are queued in a line (message-queue) with all
>> "hardware"/"GUI" events.
> Ok. So this would do nothing more than synchronize the asynchronous
> event of an expired timer to the main thread.
> Of course, the "time" of
> execution of the code associated with the expiration is now determined
> by the time the message queue is handled the next time.
You are absolutely right. (Delphi like) TTimer can't be used for
"realtime" stuff. Here you need threads and taking the pain to care
about mutual access problems is required and sensible.
> So why don't use CheckSynchronized for this?
What is CheckSynchronized ? Can this help queuing multiple (e.g. Timer)
events so that they get executed in order of their occurrence in a non
preempted way ?
To enable TTimer to work in the Delphi/Lazarus-like way, of course the
main program needs to call an RTL function that never returns and _all_
actions need to be events that are queued and handled by callbacks in
the sequence of their occurrence. Application.ProcessMessages needs to
be in place to allow a less important event granting precedence to more
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fpc-devel