On Tue, 01 Dec 2009, Adam Lubszczyk wrote:
Hi,
> When the module HRB (or pcode-DLL) is loaded dynamically , You are looking
> for whether it was once used a similar table of symbols, and then it
> recycled.
> If it is recycled, then You do not initialize static variables.
Yes,
> There is a problem to perform re-initialization ?
In current code there are no technical problems.
I resolved existing problems which made such operation very
complicated adding MT support to Harbour.
But there are some logical code aspects where unconditional
reinitialization of static variables is not good option.
I.e. some codeblock may still exists after unloading .hrb module
and use static variables from this module. When module is loaded
second time without static variable reinitialization then they
can continue their work without any problems.
Such behavior allows to load, unload and load again code which
defines new classes. Reinitialization of static variables will
cause that after reloading all class functions will try to
register the same classes again.
> Lack of initialization of static variables, of course, provides additional
> possibilities, but I think only the EXTRA. Normally, I expect that re-loaded
> the module will behave just like the first time.
> There are also other problems, such as when we have different versions of
> the same function, and in the program we load modules several times.
> Sample:
> **** hrb1.prg -> hrb1.hrb ****
> FUNCTION abc()
> LOCAL x:="HRB1: ++2 from init static 30 - Now is:"
> STATIC y:=30
> y:=y+VAL("2")
> RETURN x+STR(y,5)
>
> **** hrb2.prg -> hrb2.hrb ****
> STATIC z:=70
> FUNCTION abc()
> LOCAL x:="HRB2: --3 from 70 initalized. Now is: "
> LOCAL w:=VAL("2")
> LOCAL s:=" plus "
> s:=s+"extra "
> z:=z-w
> --z
> s:=s+"string :)"
> RETURN x+STR(z,5)+s
>
> **** main.prg -> main.exe ****
> PROCEDURE MAIN
> LOCAL i,hh
> FOR i:=1 TO 2
> ? "HRB1 load by #",i
> hh:=HB_HRBLOAD("hrb1.hrb")
> ? "ABC()->",&("ABC()")
> ? "ABC()->",&("ABC()")
> ? "HBR1 unload #",i
> HB_HRBUNLOAD(hh)
> ? "HRB2 load by #",i
> hh:=HB_HRBLOAD("hrb2.hrb")
> ? "ABC()->",&("ABC()")
> ? "ABC()->",&("ABC()")
> ? "HBR2 unload #",i
> HB_HRBUNLOAD(hh)
> NEXT
> RETURN
> ******************************
> We obtain the result:
>
> HRB1 load by # 1
> ABC()-> HRB1: ++2 from init static 30 - Now is: 32
> ABC()-> HRB1: ++2 from init static 30 - Now is: 34
> HBR1 unload # 1
> HRB2 load by # 1
> ABC()-> HRB2: --3 from 70 initalized. Now is: 31 plus extra string :)
> ABC()-> HRB2: --3 from 70 initalized. Now is: 28 plus extra string :)
> HBR2 unload # 1
> HRB1 load by # 2
> ABC()-> HRB1: ++2 from init static 30 - Now is: 30
> ABC()-> HRB1: ++2 from init static 30 - Now is: 32
> HBR1 unload # 2
> HRB2 load by # 2
> ABC()-> HRB2: --3 from 70 initalized. Now is: 29 plus extra string :)
> ABC()-> HRB2: --3 from 70 initalized. Now is: 26 plus extra string :)
> HBR2 unload # 2
>
> Strange result is not it?
> HRB2 get static value from HRB1 and vice versa !!!
It's expected behavior.
It allows to register and unregister .HRB modules dynamically compiled from
.prg code in long running programs like some servers though I can imagine
situations when user would prefer different behavior.
> Przemek, maybe can You add options to HB_HRBLOAD () which will force a
> re-initialization of static variables like: hb_hrbload( HB_HRB_INIT_STATIC,
> "hrb.hrb")
> or better: hb_hrbload("hrb.hrb") normal and: hb_hrbload(
> HB_HRB_NO_INIT_STATIC, "hrb.hrb") extra feature.
I have similar option in my TODO list nearly from beginning of my work
on .hrb code (you can find some messaged about it in this mail list archive)
but so far I haven't found time to implement it. I'll try to give higher
priority to it ;-)
Please also note that such reinitialization can be done in two different
ways:
1) by simple overloading existing static variables
2) by allocating new static variables and detaching old ones so
if some codeblocks created by previously loaded HRB module are
still alive then they will access previous instances of static
variables not the new ones.
and probably some users will also want to control it.
best regards,
Przemek
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
