All those are the basics that I apply since I'm busy writing threads
code. I already make use of Critical sections and events lock some
external resources (log files for instance) and I avoid to have any
thread code using any kind of GUI. All thread code I write, is contained
in OS services or very specialized programs having no GUI at all.
Anyway, thanks for precisions.
Just for the case you understood that wrong: There is no pricincipal
problem of threads running in a GUI app. The problems arise only if
you access some visual component (e.g. change the Caption of a Label)
without using Synchronize. If you either use Synchronize or your
threads don't access the GUI directly, then you won't have problems
with them.
Ok, sorry, confusing sentence. I mean that I'm aware of Synchronize use
(thanks to multiple crashes ;-) ) and interfacing threads with other
threads or processes (I use a shared Q of my own with, of course,
critical section, signals and events, etc to be as much independent of
OS as possible but this is another point) and I use them sometimes when
I write some thread code in a GUI application. No problem with that. In
my mind I was thinking on services which do not have (but can have) a GUI.
Again, I think it is useful to be as precise and accurate as possible on
this matters.
Thanks Sven.
E.g. the scanning of the Free Pascal source directory at the first
start of Lazarus (or when you change the source directory) is done
using a thread.
Regards,
Sven
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
