Przemyslaw Czerpak ha scritto: > > 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).
I think I was not able to explain what I intended to say .) with a MT only runtime you have two possibilities: - you write MT .prg code (startThread() and the like) - you write ST .prg (code ported from clipper) All your code should be executed by a single thread (let's say #1) and only code that is explicitly started by a startThread() should be executed by a different thread. This way, if you don't use MT extensions explicitly your code has not MT issues being confined to a single thread (as is with current ST code which is, in the end, run by a thread). > > > 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 was an example, since .prg gets compiled to .c I cannot have a ST .prg code linked to ST .C libraries if GC is to be run by a thread. If, otherwise, we have a MT only runtime than we already have to link to MT .C libraries and as such we can use threads at the .C level without worring about .prg <-> .c issues (if there are such issues, I really don't know for sure). > > 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 ok, it's clear now. > 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. > If this is so, then I'd say let's write a xbase++ compatible api, this will make it easier for third parties to support harbour as well. > > 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. > Long time ago I ported my contrib/mysql to xbase++, if I remeber correctly I can still use _parc() apis on xbase++, I just have a new set of calls, _conXXX() to deal with containers to a greater extent than it's possible using compitible extended api. But it was a long time ago, maybe I'm wrong right now :) > 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. Ok. > 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. I was not aware that xHarbour had thread local WAs :O Best regards. Maurilio. > > best regards, > Przemek > _______________________________________________ > 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
