[fpc-devel] Threads and alot of crap continued

[Michael Schnell]

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. 
Exactly
> 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 
important ones.

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20061108/1cea5202/attachment.html>