Re: processor affinity and GThread



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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]