[fpc-devel] Threads and alot of crap continued
mschnell at lumino.de
Tue Nov 7 18:30:47 CET 2006
>> The big advantage is that you do not need to protect any resources
>> from multi-threaded access if you do not explicitly create a thread
>> by means of TThread.
> And the big disadvantage seems to be a overly complicated programming
> model. Guess, what I'd prefer.
As said, we need to implement TTimer to work as it does in Delphi (and
Lazarus), as otherwise we would brake the code of everybody who ports
And using this way (something like that is sometimes called "cooperative
multitasking") is by far less complicated that it would be with real
threads (aka "preemptive multitasking"), as no protection of the objects
against multithreaded access needs to be used (hence e.g. you can use a
TList in a TTimer event while you need to use a TThreadList in a
TThread, if the list can be accessed by the main thread, too).
No Delphi program that uses TTimer would work reliably, if TTimer
would be implemented similar to a thread. As most application developers
don't ever use threads, they even are not aware that they would need to
take lots of precautions if a TTimer would be able to interrupt the main
line code at any place.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fpc-devel