We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 741

Summary: Expose thread handle for low-level use
Product: SDL Reporter: Jeroen Roodhart <jeroen>
Component: threadAssignee: Sam Lantinga <slouken>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: API change    
Priority: P2    
Version: HG 2.0   
Hardware: x86   
OS: Linux   
URL: http://xbmc.org/trac/ticket/6145

Description Jeroen Roodhart 2009-05-11 12:05:00 UTC 
Dear Icculus,

Compiling and running XBMC code on a 64-bit Linux system triggered a segfault whilst trying to access a SDL-thread as a pthread. The segfault was caused by an unsuccessful cast of (pthread_t) SDL_GetThreadID(...).

Apparently this cast works as intended on 32-bit systems. 

In my view the "proper" way to do this would be to get access to the "SYS_ThreadHandle handle" member of 
struct SDL_Thread. This could (when using pthreads) then safely be cast to pthread_t. However (in spite of commentary that states: 
/* This is the system-independent thread info structure */) there seems to be no way to acces "struct SDL_thread" through a SDL public interface.

Maybe the cleanest way of offering this functionality (when in accordance with SDL policy and technically feasible), would be to offer a method "SYS_ThreadHandle SDL_GetThreadHandle(Uint32 threadid)"

If you are able to find time, could you visit the above XBMC ticket and offer your views and advice on this (maybe you can show a method that yields the required result whilst using the current SDL interface)

With kind regards,

Jeroen Roodhart
Comment 1 Ryan C. Gordon 2009-09-13 16:27:57 UTC 
I'm kicking this to SDL 1.3 for consideration.

We should probably use some sort of opaque pointer there (or at least a Uint64, so the system can cast it to a pointer).

--ryan.
Comment 2 Sam Lantinga 2009-10-10 12:28:44 UTC 
Yeah, I'm okay with this.  I want to add thread priority and CPU affinity too.

Feel free to bounce this one to me if you want.
Comment 3 Sam Lantinga 2009-12-14 22:56:24 UTC 
I'll be giving the thread API some love, and I'll be working on how to represent this.  Possibly as a void*.
Comment 4 Sam Lantinga 2009-12-15 20:49:22 UTC 
The thread ID type is now an unsigned long (SDL_threadID) which will hold the full pthread_t on 64-bit systems.

In addition, I'll be adding some useful API functions so hopefully people will need to do this sort of thing less often. :)