On Tue, 04 Dec 2007, Maurilio Longo wrote:
> 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)
- create a code which is reentrant safe and will work in both
ST and MT modes if possible without any additional synchronization
mechanism.
This is sth what I used to do because usually I do not know how I will
want to use my code in few years - it may be part of ST or MT program.
> 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.
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
