[fpc-devel] NoGlobals branch

[Florian Klaempfl]

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?