On Tue, 04 Dec 2007, Maurilio Longo wrote: > Przemyslaw and all involved, > If I can say what I think, here it is: I'd like to have just one mode, the MT > one, and just one set of extended api, the one we have now. Then, if I don't > write .PRG level MT code I simply end up having all my code executed as thread > #1.
Fatal idea because in the same moment real thread #1 will operate on the same data as the other thread(s) which executed the same non MT code. Result: internal structure corruption and probably GPF (optimistic situation) corruption of external data f.e. stored in data files (worser case). IMO it's the worst possible choice. In such way worked xHarbour when HB_STACK_MACROS were enabled by default and hb_stack symbol was present in both MT and ST modes. > This way GC can be on a different thread, terminals can update on-screen > buffer asynchronously from .prg code and so on. Sorry but I do not understand. I do not see any relation to GC here or allocated resources. How GC will be implemented is only our decision and 3-rd party code should not depend on it at all. For us it's only important to not define API which may reduce our choices in the future. > It seems to me just a waste to have two sets of apis, two kinds of runtimes, > two kinds of libraries and so on when the overhead is a mere 5%, that is, in a > couple of months from now it will be removed by the use of faster cpus. Current Clipper compatible API does not allow to create more HVMs in single thread programs. It forces using the same number of OS threads as Harbour threads and in some cases it can be serious limitation. Please also remember about other then x86 based machines which may not follow some of modifications/extensions in the future. If need really good and flexible solution then we should create new API and remove the old one so whole code will be MT ready. > Look at xbase++, they just have the threaded model and this is a plus since > people start using it sooner or later if it does not require to rewrite things > for MT, or use different libs, makefiles etc etc. And xbase++ uses sth like proposed new API and does not support Clipper compatible one. If you want to follow xbase++ then we will have to drop current API. > With xHarbour it was decided to have two models MT and ST, and the end result > is that only ST is really used/tested/rock solid and this was, for me, a _big_ > mistake. To clarify. MT mode in xHarbour was never finished. Even the goals of MT mode was never defined. Some important core elements has been never MT safe. F.e. even such basic ones like OOP code - just check that s_pClasses is not protected so you can have unexpected GPF in OOP code, it's enough that some thread will execute code with new class what causes that s_pClasses will be reallocated and all pClass pointers used by other threads will stop to be valid. Problems with xHarbour MT mode are not caused by separate libraries but by the fact that it has been never finished and developers haven't known how to make existing and new code MT ready because it was not defined which resources should be local and which ones global. Looking at existing code does not help because it's not finished in too many places. Few months ago Miguel syncing modifications with Harbour removed from xHarbour thread local work areas and so far no one reported it as a bug. It only shows that in practice no one seriously uses MT in xHarbour and does not even know what should expect. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
