Re: GIO will link with -pthread soon

[Michael Meeks <michael meeks novell com>]

On Thu, 2009-11-12 at 16:36 +0000, Michael Meeks wrote:
> 	b) there are simple, more robust ways to indirect the 250 or so
> 	   method calls that are thread sensitive via a single vtable

	Hmm, so - having written all that nonsense - I read the glibc code; and
incredibly it does have such a vtable, and the glibc/ntpl/forward.c
methods that appear to generate the default implementation all do:

#define FORWARD2(name, rettype, decl, params, defaction) \
rettype									      \
name decl								      \
{									      \
  if (!__libc_pthread_functions_init)					      \
    defaction;								      \
									      \
  return PTHFCT_CALL (ptr_##name, params);				      \
}

	etc. via that pthread_functions vtable; which leads me to wonder -
what, in fact is the problem here - the indirection seems to be done, as
expected inside glibc - and:

	objdump -D /lib/libc.so.6

	seems to show it doing this in eg. pthread_mutex_lock.

	So - it seems the reason for it not working is more involved than
poisoning your PLT entries with non-threaded versions of methods.

	Is it possible that this is just a gdb issue ? :-) or are there indeed
some memory structures that cannot be correctly initialised after the
fact by the threading system ? [ I was never persuaded that glib's
demand to initialize threads before any other line of code was remotely
reasonable either BTW ;-]
 
	Regards,

		Michael.
 
-- 
 michael meeks novell com  <><, Pseudo Engineer, itinerant idiot