blob: cc47330666e35bac7884f161a82f2f57bf642782 (
plain)
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
|
This is a list of things that still need to be done:
* fix the signal handling re-entrancy bug that FreeBSD have left in :(
* wrap vfork (basically the same as fork())
* wrap itimer() syscalls so that the _ITIMER_SCHED_TIMER can't be trashed
* Move the md include stuff so that it appears in /usr/include/<arch>/
That way, gdb's thread stuff can be built sanely and maybe other
uthread-aware stuff can make use of it?
* Move to using -lpthread. Needs weak symbol support in all as and ld.so
implementations.
[espie@ looking at unifying toolchain]
[weak symbols put into libc. libpthread built. everything works on i386]
* Add
pthread_condattr_[gs]etpshared() -- and add warn_references
pthread_mutexattr_[gs]etpshared()
sched_setparam()
sched_setscheduler()
* Add _warn_references to the schedprio stuff
* shouldn't pthread_yield() be marked depreciated?
[it is draft 4.]
* Add thread stuff to the other archs in libc/arch/; ie change
some usages of ENTRY to SYSENTRY in some .S files and add
the new macros to their SYS.h.
[wip]
* Test that thread_init is automatically called on every arch, regardless
of whether the exe is statically linked or not.
[problems with new egcs?]
* Add UNIX98's pthread_attr_[sg]etguardsize(). This would probably be
straightforward.
* Keep a handle on how netbsd are going with their kernel threads
[argument is that openbsd is not multi-processor, so user threads will
retain stability and still give reasonable performance. talked to mwp@]
* Look into how asynchronous I/O can help us. In particular, the
(unimplemented) aio*() functions.
[doesn't help very much for 1003.1c.]
* Update the libc manual pages to describe the posix re-entrant functions.
Although this is actually trivial to do, I have to decide on a
consistent way of adding them - maybe `.Sh THREAD-SAFE FUNCTIONS' ?
Should look into standards to see what they suggest/did..
May also need to document "This is not thread-safe" for some library
functions (yet to be identified).
[Need to ask aaron@ for his opinion.]
* Find out where freebsd/netbsd use pread() and pwrite().. i think
its in the database routines mostly.
* Figure out what to do with the configuration system variables (_SC_*)
that are defined by POSIX 1003.1c (at least update sysconf(3))
* Compare with PTL (http://www3.media.osaka-cu.ac.jp/~k-abe/PTL/)
[snarfed some sparc md stuff]
* Verify that threads work with:
- perl (in-tree) [almost]
- objc (in-tree gcc)
- ssl (in-tree) [triv]
- gdb
- ports
- lang/python [yes, but a SIGCONT problem?]
- databases/mysql
- net/mrtd
- devel/glib [yes]
- www/squid
- devel/sdl [yes]
* Some ideas:
+ http://www.cs.wustl.edu/~schmidt/locking-patterns.ps.gz
http://www.cs.wustl.edu/~schmidt/TSS-pattern.ps.gz
http://www.cs.wustl.edu/~schmidt/DC-Locking.ps.gz
+ http://guir.cs.berkeley.edu/projects/osprelims/papers/Scheduler.pdf.gz
"Scheduler Activations: Effective Kernel Support for the User-Level
Management of Parallelism" by Thomas E. Anderson, Brian N. Bershad,
Edward D. Lazowska, and Henry M. Levy
* Fix ufs_select and nfs_select in the kernel to give REAL answers. [ha!]
* Clean up the way that signals are delivered to threads. Yuk.
$OpenBSD: TODO,v 1.12 2001/08/18 21:01:03 pvalchev Exp $
|
