[Xr] Can the xrs argument be removed?

[Bill Spitzak]

On Thursday 22 May 2003 12:58 pm, Carl Worth wrote:
> On May 21, Bill Spitzak wrote:
>  > I would like to recommend that you remove the "XrState*" argument from
>  > Xr, and make it work much more like OpenGL where there is an implied
>  > static context variable.
>
> Thanks for the suggestion. This would be quite convenient.

Well, I am extremely glad this was not dismissed immediately. So there is 
actually some possibility of this happening? I personally feel this is 
enormously important and would make Xr a very popular and standard interface, 
due to the ease of imbedding the calls into existing code.

> I'll confess that I don't have much experience with TLS, so I have
> some questions on the implementation. For example, what is the
> best/most portable approach?
>
> I see there's the pthread_key_create/pthread_setspecific stuff.
>
> There's also the gcc __thread extension which is documented to support
> IA-32, IA-64, SPARC (32-bit and 64-bit), SuperHitachi (SH), Alpha,
> x86-64, and S390 (31-bit and 64-bit).

I'm afraid I don't know much about it, but I was under the same impression 
you are, that it is not standard and different systems have different 
solutions. For this reason I thought it would be best to hide the 
implementation inside Xr, where it can be done with #ifdef.

> One thing that seems problematic to me is the semantics of at least
> the gcc implementation:
>
> 	When a thread terminates, any pointers to thread-local
> 	variables in that thread become invalid. [1]
>
> What could we do to either avoid or detect the problem if one thread
> tries to call XrSetState with a TLS pointer from another thread that
> has already terminated?

I think only the pointer is thread-local. The XrState structure itself is in 
normal memory, so another thread could use it. Once the thread dies nothing 
can access the pointer, but if it's value was copied somewhere the XrState is 
still available.

I think it would be a good idea to lock at the XrState level, so that only 
one thread can use an XrState at a time (I suspect this will avoid a lot of 
internal locking in XrState, but I may be wrong). If this is done and the 
thread using an XrState dies, probably nobody else could use it. Perhaps an 
interface is needed to force the XrState to unlock, a program can use this if 
it knows better, but it is considered an advanced interface that most people 
would not use.

-- 
                   ,~,~,~,~ ~ ~ ~ ~
     /\_       _|_========___         Bill Spitzak
 ~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak at d2.com