Re: processor affinity and GThread

[Sebastian Wilhelmi <seppi seppi de>]

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.

> >>(and even then for the interim), 
> >>it seems I need to know how to peel-back the opaque veneer of the 
> >>GThread abstration to retrieve the native thread id contained therein.
> > 
> > 
> > On one hand you could simply cast the GThread to a pthread_t, but I
> > would strongly advise against that.
> 
>  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. 

> > What do you think of introducing a callback, which the thread will
> > call once created. This could do all it wants with the currently
> > running thread by means of pthread_self/GetCurrentThread/whatever.
> > That would be simple, working and clean.
> 
> Assuming I didn't misinterpret "callback" I don't think a callback 
> "works" here - the test code has to know to make the call.  I really 
> don't want to involve the test code because I want to try to maintain 
> the separation of harness from test code - even as I somewhat 
> hypocritcially want to then crack the veneer of the GTread abstraction 
> :)  but for a good cause :)

:)

> 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.

> 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.

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.

Bye,
Sebastian
-- 
Sebastian Wilhelmi                 |            här ovanför alla molnen
mailto:seppi seppi de              |      är himlen så förunderligt blå
http://seppi.de