RT signals and LinuxThreads

[Robert Millan]

Hi!

I found this interesting porting problem and I plan to commit it to the
PORTING document.  Please give me some feedback.

Index: PORTING
===================================================================
--- PORTING	(revision 251)
+++ PORTING	(working copy)
@@ -280,3 +280,61 @@
     line look like "foo_SOURCES = foo.c empty.cc".  This will fool automake
     into thinking foo is a C++ program.  If you know a better way to do this,
     please let us know.
+
+
+
+RT signals
+----------
+
+kFreeBSD doesn't support POSIX RT (realtime) signals.  I hope that this
+functionality is added someday but for now it's a porting issue for us.
+
+You can detect wether RT signals are available in the system via the SIGRTMIN
+and SIGRTMAX macros (which are not defined on kfreebsd-gnu).
+
+The lack of this feature is more annoying that it might seem, as it produces
+breakage in programs that don't use LinuxThreads properly.  From the
+LinuxThreads FAQ:
+
+  "On ``old'' kernels (2.0 and early 2.1 kernels), there are only 32 signals
+  available and the kernel reserves all of them but two: SIGUSR1 and SIGUSR2.
+  So, LinuxThreads has no choice but use those two signals."
+
+  "On recent kernels (2.2 and up), more than 32 signals are provided in the
+  form of realtime signals. When run on one of those kernels, LinuxThreads
+  uses two reserved realtime signals for its internal operation, thus leaving
+  SIGUSR1 and SIGUSR2 free for user code."
+
+Since we don't support RT signals, kFreeBSD counts as a "Linux 2.0" kernel,
+and we use SIGUSR1 and SIGUSR2.  Programs are supposed to support this as long
+as they support Linux 2.0.
+
+However, another incompatibility arises.  From linuxthreads/sysdeps/unix/\
+sysv/linux/pthreadsig.h:
+
+  [...]
+  #define PTHREAD_SIG_RESTART     SIGUSR1
+  #define PTHREAD_SIG_CANCEL      SIGUSR2
+
+And from linuxthreads/sysdeps/unix/bsd/bsd4.4/kfreebsd/pthreadsig.h:
+
+  [...]
+  /* On FreeBSD, only SIGUSR1 can be used as the thread termination notification.
+     This is hardwired in the kernel.  */
+
+  #define PTHREAD_SIG_RESTART     SIGUSR2
+  #define PTHREAD_SIG_CANCEL      SIGUSR1
+
+So, we use SIGUSR1 and SIGUSR2 like on Linux 2.0, but with the peculiarity that
+the meanings of these signals are swapped.
+
+Programs with LinuxThreads-specific code that use SIGUSR1 and SIGUSR2 directly
+as thread restart and cancelation signals will do weird things.  They'll
+restart a thread when they mean to cancel it, and cancel it when they mean to
+restart it (ugh).
+
+The obvious workaround is swapping the hardcoded signals in the program code.
+I'm looking for a decent solution to this problem.  We could export
+__pthread_sig_restart and __pthread_sig_cancel in libc.  These variables are
+initialised by LinuxThreads and contain the proper value for either RT-capable
+or RT-less platforms at any time.  Any suggestions?

-- 
 .''`.   Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S)
: :' :
`. `'    http://www.debian.org/ports/kfreebsd-gnu
  `-