This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
> The time is near when we (well, I) well start a drastic move toward
> generally using thread registers. Even in non-threaded code.
Can you elaborate on this a little? Do you just mean removing the
conditionalization in __libc_tsd_{get,set} and always calling the
functions? A platform without thread registers could always just have
implementations of __libc_internal_tsd_* in -lpthread and -lc.
> Oh, this now also concerns Hurd. So, Roland, how far is using LDTs on
> Hurd/x86?
I think it might be broken now, but we cna fix it. We certainly intend to
have the feature (and/or something else equivalent for this purpose) and I
don't have a problem committing to relying on that in the libc-2.3 timeframe.
(The LDT approach is kind of gratuitous overhead for just this use of
emulating a thread register. I might instead implement a simpler plan of a
constant %gs value pointing to a single location per CPU that the kernel
updates with a thread-specific word at context-switch time.)
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |