On Thu, 18 Sep 2008, Szak�ts Viktor wrote: Hi all,
> 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. I thought about it and I think that making PUBLIC common for all threads may force code rewriting. Now we have full thread encapsulation so you can take ST code which uses memvars and use it in MT programs without modifications. If we make PUBLIC common for all threads then it will be necessary to make like THREAD PUBLIC or add synchronization code. It will be also necessary to change memvars symbol table and keep separate pointers for private and public variables. Now I decided to add thread attributes which allows to control what will happen with existing memvars when new thread is created so it's possible that child thread will have copy of all existing PUBLIC and/or PRIVATE variables or making them common (shared) with parent thread. It allows to reach nearly the same effect as in xBase++. It's enough to create new thread with HB_THREAD_INHERIT_PUBLIC attribute. There is only one difference. When thread creates new PUBLIC variable which wasn't existing when thread was created then this variable is created only for this thread. As I said above For strict xbase++ compatibility we will need to divide memvars handles to store PUBLIC and PRIVATE ones separately. If users will vote for such solution then I'll add it too. In such case we probably should also add support fot THREAD PUBLIC variables. Now let's return to GLOBALs. GLOBALs are application wide STATIC variables. If we do not want to add them then we should add support for automatic PUBLIC declaration and initialization with the same conditions as STATIC initialization. This will cover the necessary functionality. We can make it in two ways: 1. use existing syntax and only allow to declare PUBLIC out of function body just like file wide statics. The bad effects of such solution is forcing -n compilation. It also make such code harder to locate when program have to be ported for some other xbase language. 2. we will introduce new syntax, f.e. INIT PUBLIC <var1> [ := <exp1> ] [, <varN> [ := <expN> ] For me the second one seems to be cleaner. Because it's possible to initialize the same PUBLIC variable more then once in different modules then at startup HVM will detect such situation and generate internal errors. It should help with finding name conflicts in own and 3-rd party libraries and fix them immediately just after linking. Otherwise it may cause unexpected behaviors at runtime. Without such protection sometimes it maybe very hard to locate the real reason of problem. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
