a.fortuny at sitasoftware.lu
Fri Mar 23 16:28:01 CET 2012
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
> 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.
> Lazarus mailing list
> Lazarus at lists.lazarus.freepascal.org
More information about the Lazarus