ThreadId() doesn't return the thread id

Trond · Post by **Trond** » Sat Nov 10, 2007 5:17 pm

Returns the unique ID which identifies the given 'Thread' in the operating system.

The function ThreadID() doesn't return the thread id! It returns something else, maybe a handle, but it doesn't work as an id. Thread handles aren't unique, so according to the description it should be the id.

Code: Select all

Procedure MainThread(ThreadVoid)
  Debug GetCurrentThreadId_()
EndProcedure

T = CreateThread(@MainThread(), 0)
Debug ThreadID(T)
Delay(100)

srod · Post by **srod** » Sat Nov 10, 2007 6:15 pm

Yes, I noticed this with earlier versions of PB, but thought it was a case that I didn't understand thread handles properly.

Post by **freak** » Sat Nov 10, 2007 11:24 pm

It returns the value of the open thread handle. All functions that return the OS handle end with ..ID() (GadgetID, WindowID, etc).
A thread handle is unique in the system for as long as the thread runs iirc.

Just because windows has the concept of a "thread id" as well does not neccesarily mean a function
that is named that way will return that. I know that might lead to confusion in this case
but it better fits with how its handled in the other libraries.

Besides that, the thread handle is usually more useful when calling API functions
than the thread id is.

Trond · Post by **Trond** » Sun Nov 11, 2007 12:10 pm

freak wrote:It returns the value of the open thread handle. All functions that return the OS handle end with ..ID() (GadgetID, WindowID, etc).
A thread handle is unique in the system for as long as the thread runs iirc.

No, a thread handle doesn't have to be unique, but that's not the point. I read the description the other way, so that the thread handle uniquely identified a thread, which means that there is only one thread handle per thread. That's wrong. You can have 1000+ handles for each thread, the number that identifies the thread is the thread id, of which there is exactly one per running thread.

Just because windows has the concept of a "thread id" as well does not neccesarily mean a function
that is named that way will return that. I know that might lead to confusion in this case
but it better fits with how its handled in the other libraries.

It really should be written in the docs if the function called ThreadID() doesn't return the thread id. Also, the description fits only for the thread id and not for the handle, in my opinion.

Besides that, the thread handle is usually more useful when calling API functions than the thread id is.

Well, I need the ID.