www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: D2 std.thread and ThreadAddr

reply Sean Kelly <sean invisibleduck.org> writes:
fawcett uwindsor.ca Wrote:

 Hi folks,
 
 I'm crossposting this question from digitalmars.D.learn. Looking at
 D2's documentation on the std.thread module,
 
 http://www.digitalmars.com/d/2.0/phobos/std_thread.html
 
 ...there are several functions take a ThreadAddr value as an argument.
 But there are no documented functions, methods or properties one can use
 to obtain a ThreadAddr value.
 
 I assume this is a documentation error. How do you get a ThreadAddr?

I've always tried to keep the thread module completely platform agnostic so I'm not sure if these routines really should be public at all, but that aside, a ThreadAddr is a platform-dependent type. It's a pthread_t on Posix and a uint on Windows. You'd get the address using pthread_self() on Posix and whatever the equivalent is on Windows.
Apr 29 2010
parent reply fawcett uwindsor.ca writes:
On 10-04-29 07:40 PM, Sean Kelly wrote:
 fawcett uwindsor.ca Wrote:

 Hi folks,

 I'm crossposting this question from digitalmars.D.learn. Looking at
 D2's documentation on the std.thread module,

 http://www.digitalmars.com/d/2.0/phobos/std_thread.html

 ...there are several functions take a ThreadAddr value as an argument.
 But there are no documented functions, methods or properties one can use
 to obtain a ThreadAddr value.

 I assume this is a documentation error. How do you get a ThreadAddr?

I've always tried to keep the thread module completely platform agnostic so I'm not sure if these routines really should be public at all, but that aside, a ThreadAddr is a platform-dependent type. It's a pthread_t on Posix and a uint on Windows.

Thanks! If they do remain public, I'd vote to add a formal currentThread() function, and a 'ThreadAddr getID()' accessor to the library.
 You'd get the address using pthread_self() on Posix and whatever the
 equivalent is on Windows.

I believe it's GetCurrentThreadId() on Windows. As a side-question: it considered bad form for a D library to have platform-specific functionality? E.g., if for some reason Windows didn't have any function for getting the current thread-id, is there a convention that the D library shouldn't offer a "currentID()" function at all, for portability reasons? (My personal bias would be to offer it on whatever platforms supported the feature, and document its absence elsewhere; or offer a dummy-version on non-supporting platforms that caused a compilation error when user code attempted to call it.) Cheers, Graham
Apr 30 2010
parent Sean Kelly <sean invisibleduck.org> writes:
fawcett uwindsor.ca Wrote:
 
 As a side-question: it considered bad form for a D library to have
 platform-specific functionality? E.g., if for some reason Windows
 didn't have any function for getting the current thread-id, is there a
 convention that the D library shouldn't offer a "currentID()" function
 at all, for portability reasons?

Good question. One reason for not exposing the platform-specific threadId in addition to it being platform-specific is that it may allow operations that aren't supported in D. For example, you could explicitly terminate the thread, etc. I figure if you have a need to do something like this then it's reasonable to expect that you get the thread id yourself using pthread_this, etc. I can see some justification for exposing ops that accept a thread ID if it's useful for C integration (thread_attachThis, for example, might have a thread_attachById analog), but that's really it.
May 03 2010