Date: Mon, 16 Jun 2003 16:53:51 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Gareth Hughes <gareth@nvidia.com> Cc: Andy Ritger <ARitger@nvidia.com> Subject: RE: NVIDIA and TLS Message-ID: <Pine.BSF.4.21.0306161638160.19977-100000@InterJet.elischer.org> In-Reply-To: <2D32959E172B8F4D9B02F68266BE421401A6D7E1@mail-sc-3.nvidia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 16 Jun 2003, Gareth Hughes wrote: > On Mon, 16 Jun 2003, Daniel Eischen wrote: > > > > Right. It just seems wrong to me to be able to insert __thread > > after every global variable in a library and instantly make > > it thread-safe. > > Why, exactly? Surely, from a programming point of view, this is > exactly what you want -- a transparent way to access your thread > local data. I think what Dan is saying is that there is a lot more to making a program thread-safe than just banging __thread before global variables. I think that it is sad that OpenGL has been implemented this way rather than passing an "our state" variable to each API call as is usually done. Because in the real world the market leader decides the rules and because Linux has decided to make the TLS hack standard, that means that many peolpe will use it. This means that the posix standard basically goes into the trash basket of history. If the lowest level calls took the 'current drawing context' (or whatever you call it) as an argument, then it wouldn't matter so much how it was originally derived. An occasional function call to derive it would be ok. it's the fact that you decide to derive it from first principles every time rather than caching it that is the problem. __thread can easily be derived in an efficient manner in a library independent manner using an entrypoint, but making it important to do it in 1 machine instruction is not possible in a library independent manner. I think that this is a BAD THING even if we end up having to do it somehow.. BTW in my previous comment re: wine and OpenGL does wine link with openGL? If not I'd just go for using %fs for now :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0306161638160.19977-100000>