On Thu, 09 Oct 2008, Pritpal Bedi wrote: Hi Pritpal,
> > * harbour/source/rtl/tthreadx.prg > > + added xBase++ compatible TThread class. > A very well constructed class. It's your job not mine :-) I only implemented few functions. It has to be updated yet for missing functionality. But it has to be done by xBase++ user who knows this language and can validate some things which are not clear for me after reading documentation. The tests results with dbDetach() shows that even the documentation does not describe the real xbase++ behavior. F.e. it looks that xbase++ can have methods and object variables with the same name. It means that: ? o:var gives different code then: ? o:var() or at least documentation it wrong describing :atStart and :atEnd methods and variables. It's interesting functionality I even wanted to add but it's not Clipper compatible though probably we can hide the difference by introducing "suggested" action to PCODE so o:var() will work as o:var when there is no method with the name "var". If other developers think it's important then I can add such extension. One thing in THREAD class will need extension in HVM thread code if we want to implement it as in documentation: restart in the same thread after QUIT. It will be necessary to introduce new state so thread will not finish but it will wait for other jobs. But the same can also be implemented as new thread executed in the same THREAD object. I will not be surprised if xbase++ makes such things in some cases without updating threadID() number (or maybe even this number is also changed). And here is the problem. I do not want to change HVM core code only to implement some documented xbase++ behavior if I do not know if documentation is correct or if I correctly guess what xbase++ does when documentation is not precise enough. It's possible that I'll make sth what is not necessary at all because real implementation in xbase++ can be replicated using some very simple solution. I also do not know how many people will want to use it and will be interesting in full xbase++ compatibility. So I'm leaving other modifications to xbase++ users. If you will need some help or information about Harbour thread implementation then of course I'll do what I can. The thread priority I left untouched. There are very big differences between PTHREAD, MS-Win and OS2 here and 1-st I will have to think about some general Harbour layer which will be portable and which things will be usable, f.e. I do not see big sense in adding real time threads support to .prg code. Manipulating thread priority strongly interacts with concurrent execution and user need real deep knowledge about OS to know what may happen in some cases. At this moment I see as usable for users IDLE priority which means that threads is executed only when others does not need CPU, f.e. they are waiting for disk IO or sth like that. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
