From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 21 21:04:09 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 8126B16A4CE for ; Sun, 21 Dec 2003 21:04:09 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 619F443D41 for ; Sun, 21 Dec 2003 21:04:05 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id hBM544iw001439; Mon, 22 Dec 2003 00:04:04 -0500 (EST) Date: Mon, 22 Dec 2003 00:04:04 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Alfred Perlstein In-Reply-To: <20031222010257.GY60229@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 05:04:09 -0000 On Sun, 21 Dec 2003, Alfred Perlstein wrote: > * 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... [...] > 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