/usr/share/doc/dietlibc-doc/libpthread.CHANGES is in dietlibc-doc 0.33~cvs20120325-4.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 | This is the pthread implementation of dietlibc.
Written from scratch by Olaf Dreesen.
Wed Sep 17 17:03:57 CEST 2003
- add the semaphore support. (changed the internals of the manager a
little for this.)
- fixed pthread_create so that it does not change the global thread
cancel-type on error.
Mon Aug 18 17:32:52 CEST 2003
checkin.
Mon Aug 18 17:27:57 CEST 2003
more preparations for checkin
Sat Aug 16 17:35:25 CEST 2003
more cleanup. prepare for checkin
Thu Aug 14 14:16:22 CEST 2003
minor cleanups...
Wed Jul 23 16:05:28 CEST 2003
last SIGSEGV found and fixed
TODO:
- test everything in the real-world :)
Wed Jul 7 19:34:02 CEST 2003
new algorithm lead to SIGSEGV on a busy system....
TODO:
- fix the SIGSEGV
Wed Jun 4 18:55:18 CEST 2003
cleanup the internal functions (fewer calls to __thread_self())
TODO:
- test the "hash" based find algorithm
Wed May 21 13:48:56 CEST 2003
TODO:
- use a better algorithm to find a thread (act. O(n))
Mon May 19 14:40:55 CEST 2003
- the 2.5+ kernel do a SIGKILL on ALL threads if one makes a
"critical" error (SIG{SEGV,FPE,...})
Wed Apr 30 16:31:10 CEST 2003
FIXED:
- cancellation points...
- warning about structure initialization
Wed Apr 23 19:02:38 CEST 2003
WORKING STUFF:
- basic pthread functions are working.
- fork with pthread_atfork handlers working.
- unix signales are working (per thread).
If a thread is terminated by the default signalhandler (exit on signal)
the same signal is send to all threads. (e.g. SIGSEGV,SIGFPE,...)
TODO:
- async cancelation: manager lock-up (no idea for a fix yet)
Wed Feb 19 20:20:20 CET 2003
changed the __thread_self function to use the machine specific register
instead of the __buildin_frame_pointer; because the least is !? NOT !? the
stack-pointer if we omit the frame-pointer...
TODO: no changes since last time
Wed Feb 12 16:04:36 CET 2003
the basic functions are working now.
TODO:
- async cancelation manager lock-up fix
- UNIX-signal test
Thu Aug 29 16:37:18 MEST 2002
total rewrite complete...
- signal handling is now more like the standard says
- use signals for restart(join,) and cancel events
- depends on working clone,sig{set,long}jmp and __testandset
Mon Aug 19 20:40:31 MEST 2002
The signal handling is/was broken...
Changed the internal structure a bit (or better total rewrite)
Mon Aug 6 15:46:39 MEST 2001
Ups... did the wrong error handling... the error is returned not put to
errno...
probably thread_key is not SMP save...
Thu Apr 12 16:47:12 MEST 2001
added conditional variables...
except pthread_cond_timedwait all should work man-page like
pthread_cond_timedwait dosen't handle cancel request according to man-page
added thread specific key handling (all according to man-page)
Fri Mar 30 18:47:37 MEST 2001
uff found some logic errors and fixed them.
pthread_create had a problem with user provided stacks.
Fri Mar 23 14:09:54 MET 2001
arg.. the kernel-header are so inconsistent...
on x86 it works on arm and sparc not due to MISSING defines, miss-places
includes and __KERNEL__ checks....
the best in this category is that the kernel-header are changed that the
buggy (g)libc haven't to change... (f..k glibc, the headers HAVE to be
CONSISTENT)
a public defined symbol on arch X have to be in Y too unless marked...
that is mainly speaking SCHED.H ! arg....
Wed Mar 14 04:28:45 MET 2001
I have implemented the "Manager Thread" so that nested thread creation
works. really ugly stuff... don't look at it unless you're sitting on solid
ground.
Mon Mar 12 16:16:00 CET 2001
first of all:
I strongly suggest NOT to use it yet, it's very, very, ... very
experimental. I guess you got the point. there is still much debug code,
incomplete functions and unusable states....
I'm still working on the final alpha...
|