Re: processor affinity and GThread

[Rick Jones <rick jones2 hp com>]

Sebastian Wilhelmi wrote:
> Hi Rick,
>
>
> > How about a g_native_thread_id() call?-)
>
>
> What should be returned by that? Something like
>
> 	#define g_native_thread_id(thread) ((void*)thread)
>
> just for exporting something, that no-one should use? Doesn't sound very
> convincing.

What can I say, I'm a quixotic dreamer :)


> > From what little I could decipher from the .h files I didn't even know 
> > I could do that - is it the case that the native thread "thingie" :) is 
> > the first item in the GThread?
>
>
> Yes, IIRC. It's been a time, since I looked at this, so YMMV.
> But remember: Doing this will _probably_ break your application in the
> future.

I understand that completely.

> > I suppose what might work, but what I really wanted to avoid, is 
> > launching the test thread with a harness function that does the native 
> > affinity thing via pthread_self et al, and then calls into the test code.
>
>
> Why do you want to avoid that? Using a proxy function to first perform
> whatever actions you need to do and then the calling the actual function
> is a nice and clean solution, we use that idiom in GLib as well.

I suspect my reaction is mostly emotional. Perhaps formed in part by 
"old school" stuff like directly taking the thread id returned by 
pthread_create or the pid returned by fork().

One semi-practical consideration is that I'd need some 
synchronization/rendezvous between the main thread and the newly created 
thread - so the main thread knows when the native thread id is "there" 
to be seen.

> > The one problem there is it seems to preclude changing the affinity 
> > later, which is something I could do when the main netserver thread was 
> > making the affinity calls.
>
>
> No, the proxy could simply tell its own thread id to the netserver
> thread thus enabling it to use that information to perform the
> platform-specific operations.

Ah, that would be clever.  It would in effect, be a version of 
g_native_thread_id() wouldn't it?-)  I wonder how many different gthread 
applications do something like that already?

> BTW.: You can determine the currently used thread abstraction by means
> of checking, whether the preprocessor symbols 
>
> 	G_THREADS_IMPL_(POSIX|DCE|WIN32|SOLARIS)
>
> are defined. That should make the platform-specific code simple to
> integrate into your sources.

I'll go chat with my netperf4 partner in crime about using your 
suggested idiom
> Bye,
> Sebastian