After the problems with the global variables, I started another branch
for removing global variables and fixing compiler "states".
In the NoGlobals branch I already could make the scanner/parser a child
object, owned by the module. It is not yet clear, however, whether the
parser or entire modules can be destroyed before the end of compilation
- if memory requirements are of interest at all.
Unfortunately I couldn't merge this working solution for the
compiler/parser startup and shutdown into the OO_rewrite branch, so that
I'll have to continue with this new branch.
Now it becomes easier to assign further globals and procedures to
specific classes, so that finally every parser can work in its own
thread. The current_module becomes the first, and hopefully only,
candidate for a threadvar. For use in other applications a compiler
class/object could be constructed as well, and back-end classes, of course.
Since not all currently global variables can be moved into their
"natural" (owning...) classes, without causing circular references, I
started to replace e.g. current_scanner by a property.
Nonetheless many assumptions have to be corrected or specified, like a
compile_level doesn't make sense in a threaded compilation. I already
tried to replace that counter by a comparison
current_module=main_module, but this seems not to work properly. I'll
try module.loaded_from=nil in the next round.
I also found an simple workaround for the TImplementedInterfaces
problems (getcopy), that can be moved into the trunk immediately.
DoDi
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
