support for __thread

[Daniel Eischen]

On Sun, 21 Dec 2003, Alfred Perlstein wrote:

> * Daniel Eischen <eischen at vigrid.com> [031221 14:31] wrote:
> > On Sun, 21 Dec 2003, Alfred Perlstein wrote:
> > 
> > > * Daniel Eischen <eischen at vigrid.com> [031221 12:08] wrote:
> > > > On Sun, 21 Dec 2003, Alfred Perlstein wrote:
> > > > 
> > > > > * Alfred Perlstein <bright at mu.org> [031221 02:47] wrote:
> > > > > > How do I get __thread to work for me?
> > > > > > 
> > > > > > http://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html
> > > > > > 
> > > > > > it seems the assembler chokes on it?
> > > > 
> > > > We don't have support for it yet.  Why do you want it?
> > > 
> > > .) it'd be nice to have it for future work
> > > .) linux seems to have it, so does MS
> > 
> > libkse is ready to add support for it but I believe there's
> > some additional work to be done in rtld-elf first.
> 
> Well yes, but first would be getting the toolchain to emit
> proper code...

[...]

> It looks like a simple typo or format string error of some kind,
> but I have no clue where this is done in gcc, what would take
> me hours could likely been in a couple of minutes if the
> right people *kicks obrien* would respond. :)

Try kan.

> > > but mostly:
> > > 
> > > I'm porting webstone to use threads, and it uses that construct
> > > for the win32 threaded portion, it'd be really nice if we supported
> > > it so that I could make use of it instead of changing hundreds of
> > > lines of code.
> > 
> > I would discourage using __thread and instead make the API
> > better so it's not needed.  My fear is that once we have it,
> > it'll be abused in all sorts of ways.  I can understand
> > needing it for something like nvidia's OpenGL where you
> > have an existing API layered over their drivers and they
> > need to get thread-local-storage very often (tight loops).
> 
> Well, this allows the port to be pretty seamless, with minimal
> chances for bugs... I've already had a lot of issues porting
> the code because of other distractions.  I figure that supporting
> it would be nice.

Yes, for OpenGL/nvidia users mostly.  webstone looks pretty simple
to fix so it doesn't need __thread, and would benefit platforms
other platforms.  Which webstone are you using?  The same version
as in www/ports, or is there another more recent version out
there that we haven't tracked yet.

> I can give the ld.so work a shot if someone gives me a general
> idea of how to get at the linker sets and registers in C code.

Don't ask me :)

> It would be nice if it worked with libc_r as well, is there
> any chance for that?  Webstone doesn't need kernel threads
> really... the relatively lightweight nature of libc_r doing
> strictly network IO makes it an attractive solution for what
> I'm trying to accomplish.

I'd like to stay away from maintaining libc_r any further;
not that it can't be done, but with libkse and libthr around,
why?

> > > Any idea of how much effort it would take?  I have no clue as to
> > > how to fix our toolchain, gooing the work in ld.so doesn't see
> > > that awful, but it's not trivial either:
> > > 
> > > http://people.freebsd.org/~alfred/tls.pdf
> > 
> > Yes, we've been over that in either -current or -threads; I forget
> > which.  I think libkse already obeys the tls spec WRT %gs; we just need
> > some hooks/coordination into/with rtld.
> 
> As I said, I may be able to do this, but I definetly have no clue
> how to fix the compiler.
> 
> > > I want a threaded webstone so that I can generate a lot more load
> > > with wimpier client boxes on FreeBSD.
> > >
> > > Right now doing hundreds of connections nearly kills my desktop,
> > > but when threaded it barely hiccups.
> > 
> > There is always pthread_[gs]pecific which is what normally should
> > be used.
> 
> That doesn't lend itself to a "clean" port.

I looked at the port and it should be easy enough to fix it so
that it does support threads without TLS.

> I'll need to extensively modify the source to do that, I can
> but was hoping that I could guilt people into getting on the
> bandwagon wrt __thread. :)
> 
> > > Also, in re: thread things:
> > >  http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/60477
> > > :(
> > 
> > There were some thoughts on restructuring our name lookups so
> > that they would be thread-safe.  I would rather see that than
> > littering __thread around libc.
> 
> I actually don't have any intention of polluting libc with __thread.
> I was just whining about yet another issue (I actually hit it with
> webstone, but there's a workaround which is to make sure that the
> domain name resolves exactly to what you have in the config file,
> that avoids threaded name lookups.)
> 
> I think I can actually fix our libc functions to use thread local
> storage if I ever get around to it.  As long as threads copy the

I'd rather see a thread-safe function(s) instead of using __thread.

> return value from gethostent/getservent and don't just hand the
> pointer to another thread they should be fine, although it would
> act "funny" if threads expected to be able to iterate through the
> hostent/servent files by having several threads call the functions
> expecting each to get alternating lines.
> 
> Any thoughts on this?  Supposedly the interfaces that make sense
> (the ones that use the host_data parameter) are depricated on some
> UNIX versions already, and honestly the glibC and Solaris ones are
> just STUPID. :(

I haven't looked at any of the gethost* functions too much.  I think
Jacques Vidrine (nectar) was looking into this.

-- 
Dan Eischen