Viktor, I agree, publics should be public :) between threads with synchronization left to the user.
This has the advantage to be xbase++ compatible. I think that on mt issues we should be compatible with xbase++ which is now the "de facto" standard. Best regards. Maurilio. Szakáts Viktor wrote: > 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 > -- __________ | | | |__| Maurilio Longo |_|_|_|____| farmaconsult s.r.l. _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
