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 - Expose thread handle for low-level use
Summary: Expose thread handle for low-level use
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: thread (show other bugs)
Version: HG 2.0
Hardware: x86 Linux
: P2 API change
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL: http://xbmc.org/trac/ticket/6145
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-11 12:05 UTC by Jeroen Roodhart
Modified: 2009-12-15 20:49 UTC (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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. :)