Hi Przemek, Mindaugas,
We have few choices. F.e. we can add automatic memvars inheritance
so each child thread will share all parent thread memvars visible
when thread was started as its own PUBLIC variables.
The variables will be shared so you will have to add your own
synchronization code if you want to change them (write operation).
Such method is natural for our memvar code and can be easy
implemented.
AFAIK xbase++ shares public variables between threads. But I do not
know
detail behavior of such solution in some strange situation (f.e.
thread
declares public when some other threads or even this one have private
variables. Clipper in such case overwrite private and do not create
public one. I do not know if exact implementation of above feature
will
not interact with Clipper compatibility. I can try to implement it
respecting only Clipper behavior. It should be enough to keep public
handles separated from privates and use them when there is no private
handle with the same symbol. As 3-rd option we can add support for
GLOBAL variables though implemented without hardcoded links like in
xHarbour but by dynamic symbol table so they will work also with .hrb
files and will not reduce the speed in code which does not use them.
For now, I'd personally vote to make PUBLICs visible for
all threads (otherwise most apps would need to be rewritten
in this respect I guess), and PRIVATEs to the threads that
define them. 'THREAD PUBLIC' could be introduced to create
PUBLICs visible only for the current thread if someone
needs such thing. It would be analogous to THREAD STATIC.
[ BTW, it's difficult to stay 100% Clipper compatible
here, as we're having situations which were nonexistent
in the Clipper-era. MT-enabled code is essentially
non-Clipper compatible anyway, so if we can keep ST
behavior Clipper-compatible, I think it's no problem to
deviate from 100% compatibility for MT cases. ]
Can someone check XBase++ behaviour?
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
