$OpenBSD: TODO,v 1.16 2001/09/05 02:54:12 fgsch Exp $ 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// 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://www.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 - audio/xmms - bechmarks/iozone - databases/mysql - devel/glib [yes] - devel/sdl [yes] - graphics/ggi - graphics/gii - lang/tcl/8.3 - lang/python [yes, but a SIGCONT problem?] - lang/python15 - net/icecast [partially] - net/mrtd - net/xchat - net/pdnsd - www/squid * 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. * Make getaddrinfo(3) thread-safe. * What to do with gethostby*_r(3)? * Look into getpw*_r(3).