Hi folks,
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++
Sorry to jump in, but I had the impression this
is our number. IMO hb_threadID() should return
the Harbour value, not an OS one. If there is a
separate OS level one, IMO it should be returned
by some internal function (or maybe direct OS API),
because such code could easily break portability
on the Harbour level.
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.
[ My vote for this. ]
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
