support for __thread

[Alfred Perlstein]

* 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...

Redhat Linux's gcc 3.2.2 will output:
.globl x
        .section        .tbss,"awT", at nobits
        .align 4
        .type   x, at object
        .size   x,4
x:
        .zero   4
        .ident  "GCC: (GNU) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)"

ours:
.globl %lx
        .section        .tbss,"awT", at nobits
        .p2align 2
        .type   %lx, @object
        .size   %lx, 4
%lx:
        .zero   4
        .ident  "GCC: (GNU) 3.3.3 [FreeBSD] 20031106"

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. :)

> > 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.

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.

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.

> > 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'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
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. :(

-- 
- Alfred Perlstein
- Research Engineering Development Inc.
- email: bright at mu.org cell: 408-480-4684