Threads

[Jim Kingdon]

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