Re: OpenGL and the LinuxThreads pthread_descr structure

[Gareth Hughes <gareth dot hughes at acm dot org>]

Ulrich Drepper wrote:
> 
> Everything which is not part of glibc is third-party.  It's the same as
> if some program would require access to internal data structures of
> libGL.  There are several different layouts of the thread descriptor and
> it's only getting worse.  The actual layout doesn't matter since
> everything is internal to glibc and the other libraries which come with
> it so this is no problem.

I don't understand the reference to the multiple layouts of the thread 
descriptor structure.  Can you exlain this?

> Beside, I don't understand why you react like this.  Using __thread is
> the best you can ever get.  It'll be portable (Solaris 9 already has the
> support as well) and it's faster than anything you can get to access the
> data.

I disagree that __thread is the best you can ever get.  In the best 
case, you have an extra load and subtraction before you have the address 
of a thread-local variable.  In the worst case, you have a function call 
in there as well.

That is:

	movl %gs:0,%eax
	subl $foo@tpoff,%eax
	movl (%eax),%eax
	jmp *1234(%eax)

versus:

	movl %gs:32,%eax
	jmp *1234(%eax)

for instance.  When the function you are jumping to consists of five or 
six instructions, say, an extra two instructions are significant.

Recall that a competing operating system on x86 allows access to the 
context and dispatch pointers with two instructions, so what you are 
suggesting will mean we always have an inferior implementation.

You also need -fpic, which burns a whole register.  This is a 
non-trivial sacrifice, particularly on x86.

Let's be clear about what I'm proposing: you agree to reserve an 
8*sizeof(void *) block at a well-defined and well-known offset in the 
TCB.  OpenGL is free to access that block, but only that block.

-- Gareth