On Thu, 02 Oct 2008, Maurilio Longo wrote: Hi Maurilio,
> > Why you cannot use hb_threadSelf()? > Because I'm used to use a thread id which is a number, this is the way it > works on OS/2 and xbase++ on win32 and I did not find something similar in > current code. Not all OSes have to support numeric thread ID. If you need number then we will have to intorduce our own numeric number just like in xbase++ > > It also returns valid identifier which is compatible with values returned by > > hb_threadStart(). > See above. But you haven't explained why numeric value is better then pointer. > Yes, but on every given platform it identifies currently running thread in a > way which is clear and which can be passed to other OS APIs. ??? Where did you found such information? In some OSes thread ID can be even complex structure and we can use only pointer to this structure casted to number what is potential GPF problem when you pass wrong numeric value. Using pointer item is much more safe because it eliminates such risk. I also do not want to create to much hb_threadID*() functions like in xHarbour where you have: THREADGETCURRENT() THREADGETCURRENTINTERNAL() GETCURRENTTHREAD() GETTHREADID() GETSYSTEMTHREADID() and I never remember what each of the above function returns for given platform and I have to look at source code to find an answer. Now if I understand you need continuous number allocated for each HVM thread like threadID in xbase++. OK. We can introduce such numeric thread IDs. We can also map thread ID to number though in some OSes it will be memory address and I'm afraid that some .prg code which may expect continuous numbering will not be well portable. > I don't expect to exchange thread IDs with processes running on different > platforms, so an internal, harbour only, ID is of no pratical use, IMHO. I do not talk about it. > see above and I thought hb_threadSelf() was returning a thread object, not a > numerical ID It returns pointer item you can well use to make == comparison to identify the thread. You can also display it by simple: ? tdID If you want to use OS level thread ID in some C functions then using pointer items is also much better because the C code can validate if given parameter is valid HVM thread ID. It's enough to add C function like: BOOL hb_threadGetOSID( PHB_ITEM pThread, HB_THREAD_T * id ) => fValid > > If you need continouse thread IDs registered by HVM then we can add > > such functionality. We can use 64bit counter so we will not have to > > worry about repeated values. We can also add support to return OS > > thread ID, f.e.: hb_threadOsId(). > > The question is only what we need. I also suggest to use clear names. > > F.e.: > > hb_threadVMID() -> incremented by us integer number > > hb_threadOSID() -> OS thread ID which can be reused by some .c functions > I needed it just to see what test the modified speedtst.prg was executing and > in which thread. ? thID, ":-)" > > I expected bigger difference. I'll look at the code. maybe I'll update > > it to use more threads. > I think a lot of time is spent inside mutexes (aquiring them). Harbour in practice does not use any of such mutexes. Only some few small peaces of code are covered by them and it's small chance that two threads will be serialized. The cost of setting/releasing mutexes is the same for one and two threads so it's unimportant in such test. It has to be sth different. > > Because it does not have parent thread which may need to join it. > > It's detached for us. Just simply th_id does not mean what you thought. > I'm not used to 'join' threads, I see them as 'separate' entities which live > their life, I can wait a thread and, as such, I can also wait thread one. It does not mean that other programmers will not want to use one of the most import MT programming functionality :-). When threads are executed to make some jobs and then you want to collect results then it's enough to join threads collecting its results without introducing some additional structures and synchronization mechanism. > More in general, I think all threads should be equal, thread one is just the > first started. On a ST program it is the thread which executes the process; > this makes code which deals with threads more uniform since it has not to have > a separate, special case for thread one (or zero). We do not have any of such special thread except the one which was executed by hb_vmInit() and is finished by hb_vmQuit(). Inside hb_vmQuit() it sends QUITE request to all working threads waiting for them before HVM resources will be deallocated. This behavior will be very important when Harbour is embedded in some other system which has to be sure that all Harbour threads finished after calling hb_vmQuit(). If it's necessary then I'll add internal continuous numbers to use as hb_threadID() so you will have similar to xbase++ results on all platforms though so far I though about adding such numbers only to TTHREAD() object. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
