• Sean Kelly (2/14) Apr 29 2010 I've always tried to keep the thread module completely platform agnostic...
• fawcett uwindsor.ca (16/35) Apr 30 2010 Thanks! If they do remain public, I'd vote to add a formal
• Sean Kelly (2/8) May 03 2010 Good question. One reason for not exposing the platform-specific thread...

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.

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

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.