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 |
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel