[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

back at work

Hash: SHA1

I'll hopefully be back to work on the remaining x86 nptl issues this
week.  All this activity couldn't have been at a worse time for me
personally since I am forced to do some other high priority work these
days (beside being away for a week).

Anyway, I appreciate the patch Luca came up with and am of course
thrilled by the results.  I'll have quite some cleanup to do, though.

As for the general comments made in the last week or so: Jakub replies
wrt errno + TLS are correct.  We cannot add hacks into ld.so just to
help broken program since this would greatly reduce performance of
correctly written code.  From day one we had __errno_location support.
If people insist, after 7+ years with the old thread code, to write
broken code it's their problem.  We have an easy way out (lying about
the kernel version as Jakub pointed out) to work around the problem.

Wrt to the conditional variable code.  I have already started looking at
this, it's just not yet finished.  Writing the actual replacement code
is at this point not really useful.  It's probably much harder to review
 code than to write it myself.

And a final thing: ports to other hardware other than P6+ class x86 is
going to happen right after stablelizing the current code.  I'll be
working first on x86-64 since it's also going to be an asm-code port.
The next in my scope will be ia64.  This will be an C code port since I
have no intention to follow the ever changing scheduling requirements of
the architecture.  Beside, ia64 has the nice __sync_* builtins which
remove the unfortunate C-asm-C boundary problems which made me use pure
asm code for x86.  This C code is than available to all the other ports.

The reason I want to see ia64 as the first C code port is that the
__sync_* builtins should be used as a model for the atomic operations
used in the other C code ports.  I.e., I'd like to see equivalents to
ia64 gcc's <ia64intrin.h> header for the other architectures.

If somebody wants to get started on the C code right away this wouldn't
be a problem at all.  It would be rather good instead.  But let me know
before you start and don't just send me finished code since I want to
review it and point out problems before too much code is written.

As for problems using the nptl code: not everybody is as adventurous as
Luca and uses nptl as the system's libpthread.  That's still the
recommended practice.  I'm not sure we handle all dlopen+TLS issues
right.  I'll try to investigate all this soon.  So for now, use the
mechanisms to link with the nptl library and a locally built glibc as
described in the original announcement of nptl.  Somebody provided a
like to the message in a post to this list.

Once I looked over all the pending patches and everything works for me
I'll make a 0.5 release.  But before that can happen we need one more
gcc patch.  Jakub will hopefully have it ready this week, along with a
change to the branch for the RH gcc on sources.redhat.com.  From there
everybody will be able to pick up the change.  The configure scripts
will enforce the use of the new gcc.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
Version: GnuPG v1.0.7 (GNU/Linux)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]