Am 11.08.2010 16:09, schrieb Hans-Peter Diettrich: > 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.
This sounds good. > 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. I don't think that a parser and a scanner instance will take much memory? > > 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. I don't think that threadvars really hurt if it resolves the cyclic dependencies. > > 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. Why not? > 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. Which commit is it? _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
