At the recent open source database summit[1], I asked the developers there whether people had problems with threads on Linux.
The answer I got was that the semantic differences from POSIX weren't really a problem, but they really, really wanted better debugging. Monty (of MySQL) also suggested a few additions to our libpthread.txt file: the threads code in libc usurps SIGUSR1 and SIGUSR2, and dumping core only affects a thread, not the whole process. I've checked in those changes; I've enclosed a URL for libpthread.txt and also the current contents of libpthread.txt. [1] http://www.osdn.com/conf/osd/conf_index.shtml http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/spec/baselib/libpthread.txt?rev=1.7&content-type=text/x-cvsweb-markup&cvsroot=lsb ------------------------------ start of libpthread.txt: <PARA> The semantics of system calls do not follow the pthread behavior. This is the result of using clone() instead of lightweight processes. A complete list of differences is not yet available, so applications are discouraged from using pthreads. </PARA> <PARA> POSIX specifies a concept of per-process rather than per-thread signals. The LSB does not require this behavior; traditional Linux implementations have had per-thread signals only. A related issue is that applications cannot (using legacy Linux implementations, at least) rely on getpid() returning the same value in different threads. </PARA> <PARA> Note: one implication of per-thread signals is that a core dump (for example) may not stop all threads in a given process. This may be an issue when designing ways to stop/start applications. </PARA> <PARA> Applications which create child processes (using fork() and the like) must then wait for them (using waitpid() family of functions) in the same thread as they created them. Note that coding applications this way will work both with full POSIX threads and legacy Linux thread implementations. </PARA> <PARA> POSIX specifies that changing the user or group id instantly affects the behavior of all threads. This behavior is not specified; applications must use their own lock if they need this behavior. Rationale: it seems unnecessary and it is a performance hit (an SMP kernel must lock the user id). (FIXME: is this our current understanding? It was discussed on lsb-spec on January 2000 but I'm not sure we reached a consensus). </PARA> <PARA> Although this standard doesn't have a way to list processes (/proc or "ps" command line isn't in, right?), it is our intention to not specify one way or the other whether multiple threads appear as separate processes or as a single process. </PARA> <PARA> Applications cannot rely on resource limits (getrusage and setrusage) being maintained per-process rather than per-thread. </PARA> <PARA> Applications must disconnect from the controlling tty before pthread_create (FIXME: have I summarized this correctly?). </PARA> <PARA> times() doesn't account for all threads, just the caller. </PARA> <PARA> Applications must not call pthread_cancel if they call any system libraries (most notably X windows), as system libraries are not guaranteed to be thread safe. Likewise, for such libraries, only one thread per process may call them. </PARA> <PARA> Applications cannot rely on fcntl/lockf locks being visible per-process rather than per-thread. Likewise for mandatory file locks. </PARA> <PARA> Threaded applications cannot use SIGUSR1 or SIGUSR2. </PARA> ------------------------------ end of libpthread.txt -- Jim Kingdon Content and community, sourceforge.net, Sunnyvale, CA cell phone: +1 202 297 3567
