Re: support for __thread
In the last episode (Dec 22), Daniel Eischen said: > 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? Do gdb and pstack (in ports) handle libkse or libthr threads? libc_r is a great debugging tool, if nothing else. I can't even attach to a libkse-threaded program with gdb; the tracee gets SIGSTOP'ped, and gdb just sits there. You have to kill -9 gdb from another tty, and the tracee dies. gdb can attach to a libc_r program, view all the threads, and detach without affecting the tracee. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB link cables.
In message <[EMAIL PROTECTED]>, "Daniel O'Connor" wrote: >On Monday 22 December 2003 14:39, David Gilbert wrote: >> Has anyone looked into supporting USB link cables? I see a number of >> these on eBay ... they appear to have two usb host connectors and some >> small bit of electronics (by the description). Are these propriatary >> ... or is there some sensible way this would work? > >There's a linux driver for some models. >http://www.linux-usb.org/usbnet/ > >If it's FreeBSD to FreeBSD and they both have firewire you could use if_fwe >(which is nonstandard unfortunately). > >Of course there's also ethernet :) man udbp(4). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB link cables.
On Monday 22 December 2003 14:39, David Gilbert wrote: > Has anyone looked into supporting USB link cables? I see a number of > these on eBay ... they appear to have two usb host connectors and some > small bit of electronics (by the description). Are these propriatary > ... or is there some sensible way this would work? There's a linux driver for some models. http://www.linux-usb.org/usbnet/ If it's FreeBSD to FreeBSD and they both have firewire you could use if_fwe (which is nonstandard unfortunately). Of course there's also ethernet :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: support for __thread
On Sun, 21 Dec 2003, Alfred Perlstein wrote: > * Daniel Eischen <[EMAIL PROTECTED]> [031221 14:31] wrote: > > On Sun, 21 Dec 2003, Alfred Perlstein wrote: > > > > > * Daniel Eischen <[EMAIL PROTECTED]> [031221 12:08] wrote: > > > > On Sun, 21 Dec 2003, Alfred Perlstein wrote: > > > > > > > > > * Alfred Perlstein <[EMAIL PROTECTED]> [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 >
USB link cables.
Has anyone looked into supporting USB link cables? I see a number of these on eBay ... they appear to have two usb host connectors and some small bit of electronics (by the description). Are these propriatary ... or is there some sensible way this would work? Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: support for __thread
* Daniel Eischen <[EMAIL PROTECTED]> [031221 14:31] wrote: > On Sun, 21 Dec 2003, Alfred Perlstein wrote: > > > * Daniel Eischen <[EMAIL PROTECTED]> [031221 12:08] wrote: > > > On Sun, 21 Dec 2003, Alfred Perlstein wrote: > > > > > > > * Alfred Perlstein <[EMAIL PROTECTED]> [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 - Re
Re: support for __thread
On Sun, 21 Dec 2003, Alfred Perlstein wrote: > * Daniel Eischen <[EMAIL PROTECTED]> [031221 12:08] wrote: > > On Sun, 21 Dec 2003, Alfred Perlstein wrote: > > > > > * Alfred Perlstein <[EMAIL PROTECTED]> [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. > 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). > 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. > 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. > 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. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: support for __thread
On Sun, 2003-12-21 at 12:08, Daniel Eischen wrote: > On Sun, 21 Dec 2003, Alfred Perlstein wrote: > > > * Alfred Perlstein <[EMAIL PROTECTED]> [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? >From what I understand, having thread-local variables would be a big bonus for OpenGL. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: support for __thread
* Daniel Eischen <[EMAIL PROTECTED]> [031221 12:08] wrote: > On Sun, 21 Dec 2003, Alfred Perlstein wrote: > > > * Alfred Perlstein <[EMAIL PROTECTED]> [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 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. 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 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. Also, in re: thread things: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/60477 :( -- - Alfred Perlstein - Research Engineering Development Inc. - email: [EMAIL PROTECTED] cell: 408-480-4684 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: support for __thread
On Sun, 21 Dec 2003, Alfred Perlstein wrote: > * Alfred Perlstein <[EMAIL PROTECTED]> [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? -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: support for __thread
* Alfred Perlstein <[EMAIL PROTECTED]> [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?
Taking this code:
#include
__thread int x;
int
main(int argc, char **argv)
{
printf("duh:\n");
return (0);
}
Running it through "gcc -S" results in an asm file that has this
at the end:
.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"
as(1) will accept this file if I replace all occurrances of
'%lx' with 'lx', it then appears to create special section
called tbss, (this is used for automatic thread specific
data).
Where is the bug, the compiler or the assembler, anyone have
a fix?
--
- Alfred Perlstein
- Research Engineering Development Inc.
- email: [EMAIL PROTECTED] cell: 408-480-4684
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
support for __thread
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? -- - Alfred Perlstein - Research Engineering Development Inc. - email: [EMAIL PROTECTED] cell: 408-480-4684 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
