It's rather straight forward to do completely distinct threads.
The tricky part starts, when the threads need to communicate (which
always is necessary) and thus share some data.
Here you need to be aware of several things:
- the components and functions in the LCL and RTL usually are not
thread-save (and there is no documentation on in what way they are
"partly thread safe) e.g.
- - Many simple functions like IntToStr() seem to thread safe, but
this is not documented.
- - You can't use any function that accesses the GUI in another thread
but the main thread.
- - You can happily use multiple instances of TList in multiple
threads as long as each a single instance is not used by multiple threads.
- - You can use the same instance of TList in multiple threads if you
use a TCtriticalSection (e.g. one for each instance of TList) do block
concurrent accesses.
- - AFAIK, the way TThreadList is used with multiple threads is
documented.
- To have a worker thread communicate with the main thread (i.e. to
have it use the GUI in any way) you can use TThread.Synchronize.
Downside: The thread waits until any scheduled main thread activity is
done before entering the synchronized code (might last forever). It only
goes on working when the synchronized code is done.
- To trigger a main thread activity without having to wait for the
main thread you can use Application.QueueAsnycCall.
- The functionality of TThread.Synchronize and
Application.QueuAsyncCall is not available in all Widget Types (see
Compile-Options -> Build Modes). It is verified to work decently in GTK
and Win32 (and supposedly QT, but I did not check this myself).
-Michael
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
