From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 21 17:03:00 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02BF216A4CE for ; Sun, 21 Dec 2003 17:03:00 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 085EE43D5A for ; Sun, 21 Dec 2003 17:02:58 -0800 (PST) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 02F175C791; Sun, 21 Dec 2003 17:02:58 -0800 (PST) Date: Sun, 21 Dec 2003 17:02:57 -0800 From: Alfred Perlstein To: Daniel Eischen Message-ID: <20031222010257.GY60229@elvis.mu.org> References: <20031221203311.GW60229@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Mailman-Approved-At: Sun, 21 Dec 2003 17:15:17 -0800 cc: hackers@freebsd.org Subject: Re: support for __thread X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2003 01:03:00 -0000 * Daniel Eischen [031221 14:31] wrote: > On Sun, 21 Dec 2003, Alfred Perlstein wrote: > > > * Daniel Eischen [031221 12:08] wrote: > > > On Sun, 21 Dec 2003, Alfred Perlstein wrote: > > > > > > > * Alfred Perlstein [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",@nobits .align 4 .type x,@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",@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@mu.org cell: 408-480-4684