Przemyslaw Czerpak wrote: > > But you haven't explained why numeric value is better then pointer. Because when you print it it is more 'natural' or easy to the eye than a 0x03938474 or something like that.
That said, you're the master here, I did not want to introduce inconsistencies in the way threads are handled in harbour, so feel free to remove/change it as it best fits the overall design. As I said I needed it just to see what happens in my modified speedtst- > Now if I understand you need continuous number allocated for each HVM > thread like threadID in xbase++. > On OS/2 they're numerated like this, xbase++ was born on OS/2 and maybe mutuated this numbering scheme from it. > OK. We can introduce such numeric thread IDs. I'd like this possibility. > It returns pointer item you can well use to make == comparison to identify > the thread. You can also display it by simple: > ? tdID Can I print it as ? hb_threadSelf() what is tdID? a public? > 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 > Ok. >>> 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 As I said I just needed a way to number output and there was nothing available . >> I needed it just to see what test the modified speedtst.prg was executing and >> in which thread. > > ? thID, ":-)" > See above >>> 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. > I'll keep diggin though :) >>> 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. > Ok, this is really a good thing. Thanks a lot for the explanations. Maurilio. -- __________ | | | |__| Maurilio Longo |_|_|_|____| farmaconsult s.r.l. _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
