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@xxxxxxxx | är himlen så förunderligt blå http://seppi.de _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
