[fpc-devel] Threads and alot of crap continued

[Michael Schnell]

>> 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 
his application.

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.

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