[Xr] Can the xrs argument be removed?
spitzak at d2.com
Thu May 22 14:03:44 PDT 2003
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. 
> 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
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
More information about the cairo