[fpc-devel] Why/how does the compiler have a non-trivial numberofmemory leaks after over two decades of development?

Sven Barth pascaldragon at googlemail.com
Mon Jul 30 23:08:24 CEST 2018


Am 30.07.2018 um 19:55 schrieb J. Gareth Moreton:
> Correct me if I'm mistaken, but I believe one shortcoming with the 
> Free Pascal Compiler, despite its speed, is that it isn't 
> multi-threaded.  It can't compile multiple independent units at once, 
> and probably won't be able to for a while due to the use of global 
> variables in the node builder.  When it comes to building Lazarus and 
> the compiler, this is gotten around by the Makefiles running several 
> instances of the compiler on different processes, building independent 
> packages that can later be linked.
>
> I personally think that if the compiler can be made multi-threaded, 
> then projects like OpenSceneGraph might see a huge improvement in 
> compile times if the compiler is smart enough to identify units that 
> don't depend on each other and compile them in parallel.  I'm not sure 
> how cross-compatible it can be made, since different platforms 
> approach multithreading in different ways and I've noticed that the 
> compiler tends to avoid using SysUtils and Classes and the like (so no 
> using TThread for now).
>
TThread is not a necessity. It's functionality and the synchronization 
primitives are based on what TThreadManager provides. This manager 
resides in the System unit and is accessible through functions like 
BeginThread and such. Please note however that this might need an 
external thread manager on certain platforms (e.g. Unix-like systems) 
and the idea on those platforms is for the compiler *not* to rely on the 
C-library.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20180730/b699051e/attachment.html>


More information about the fpc-devel mailing list