Hi Przemyslaw, Przemyslaw Czerpak wrote: > 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. > It also returns valid identifier which is compatible with values returned by > hb_threadStart(). See above. > If we need yet another thread identifier then we can add it but it should > give some additional information. th_id is not good choice because it's > platform dependent low level value. In PTHREAD and OS2 is OS thread ID. > In MS-Windows is OS handler to given thread. Farther when thread is detached > then this value is cleared and can be reused for new threads in some systems. > 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. 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. > identifiers returned by hb_threadStart() and hb_threadSelf(). see above and I thought hb_threadSelf() was returning a thread object, not a numerical ID > 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. > 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). >> I,ve also noted that thread 1 has a threadid of 0 (zero) while the other >> threads have the correct id, maybe this is a minor glitch to correct. > > 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. 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). 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
