Przemyslaw, What I was trying to say is that a MT only rtl/hvm can be used with ST code (like all legacy code) without problems because code that does not use MT features explicitly will simply be running on thread #1 and will be completely unaware of being run in a MT capable environment.
This is what happens with xbase++ which has only a MT runtime. Of course, if I call startThread() I'm writing MT code and as such it will be my resposability to create reentrant/mt-safe code. Hope this is more clear. Thanks. Maurilio. > I do not understand such limitation. Code started by StartThread() > should be able to use all existing features and functions just like > single thread code. Of course if access to some resources will need > additional synchronization mechanism then it will have to be used. > We only have to clearly document which elements are synced by us and > which one must be synced by user. > > > 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). > > Maurilio, I really do not know what I should think about. Probably > I do not understand you. If I have ST server for single user in ST > mode then having MT mode I want to use the same code to serve more > clients simultaneously. I do not want to rewrite this code using > some new rules. I expect the code executed after StartThread() > will work with the same conditions as in single thread program > or as in the main 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). > > We do not have any problem with .prg->.c code translation by compiler > in ST and future MT mode. > The GC problem is caused by the fact that we have to stop all user threads > before we begin to mark all known items. If we will not make sth like that > then it will be possible that one of threads will move not marked yet chain > of items to item which has been marked by GC. It will cause that GC will > never mark them as used and free them but in fact items are still accessible. > To resolve this problem is necessary to stop all user threads or extend GC > by introducing state markers (colors in some terminology) though it's not > perfect solution and in some cases may be reason of bad side effects so > it's rather seldom used feature. > In summary: with current GC nothing can change item contents during GC > scan/mark pass. In MT programs it means that all user threads will have > to be suspend and when GC will finish its job resumed. Such situation > is quite common in many different languages using GC. > > > > 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. > > As I said such API will have to be very similar in all languages so some > set of #define macros should probably resolve the problems with portability > xbase++ code. I belive that now you can see how important is not accessing > HB_ITEM internals from non core code. In Harbour for non core code PHB_ITEM > is mapped to void * so it works just like an container handle in xbase++. > We are free to introduce any modifications without effecting 3-rd part code, > f.e we can internally use synchronization mechanism to guard that some > operations on items will be atomic or instead of pointers begin to use > indexes to some HVM internal item table. In xHarbour HB_ITEM members are > visible and accessed by non core code so it's hard to make such modifications > even in CVS repository only - instead of few modifications in HVM code it will > be necessary to update RTL and many other libraries. > > > > 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 > > :) > > looking at xbase++ C API description I can find _par*() and _ret*() > functions very similar to Clipper ones but they need as one of parameters: > XppParamList pList > what in practice means the same as passing pointer to HB_STACK. So they > have the same names as Clipper ones but needs different parameters so > works like proposed new MT friendly API. > > > > 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 > > To be more clear: the WA list was common to all threads but each thread > had its own current workarea number so it was possible that each thread > was operating on different workarea. Now current workarea number is common > to all threads so it's not possible to even use aliased expressions in > MT code because they need to switch and restore workarea number and such > operation is not thread local in current xHarbour code. > > 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
