<HTML>
<div>Well, if a certain platform relies on an external library, multi-threading could be disabled on that platform through a flag of some kind, at least until something can be programmed for that platform (or more conservatively, only enabled if it's known to work without any hitches). Just an idea. I can't remember off-hand a good enumeration set to include such a flag in though. If multi-threading is not supported, then it can just run single-threaded as it does now.<br>
</div><div><br>
</div><div>Gareth aka. Kit<br>
</div><br>
<br>
<br>
<span style="font-weight: bold;">On Mon 30/07/18 22:08 , Sven Barth via fpc-devel fpc-devel@lists.freepascal.org sent:<br>
</span><blockquote style="BORDER-LEFT: #F5F5F5 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT:0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
<defanged_meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<defanged_body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Am 30.07.2018 um 19:55 schrieb J.
Gareth Moreton:<br>
</div>
<blockquote type="cite" cite="mid:1803.1532973353@web-cluster.fastnet.co.uk">
<defanged_meta http-equiv="content-type" content="text/html; charset=utf-8">
<div>
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.</div>
<div><br>
</div>
<div>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).<br>
</div>
<div><br>
</div>
</defanged_meta></blockquote>
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.<br>
<br>
Regards,<br>
Sven<br>
_______________________________________________<br>
fpc-devel maillist - <a href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a><br>
<a target="_blank" href="<a href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a>"><span style="color: red;">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</span></a><br>
<br>
</defanged_body></defanged_meta></blockquote></HTML>