Re: Is thread support available under Linux 2.2.14?

From: Andi Kleen (
Date: Thu Jan 03 2002 - 20:05:28 GMT

On Thu, Jan 03, 2002 at 11:42:00AM -0800, Russell Browne wrote:
> My Linux system has signal 32 as __SIGRTMIN, while the code in obj_signal.c
> expects this macro to be _SIGRTMIN.  Adding the following at about line
> 133 of  obj_signal.c, just before the use of _SIGRTMIN, should give
> control over the handling of signal 32:
>    #if defined(__SIGRTMIN) && !defined(_SIGRTMIN)
>    #define _SIGRTMIN __SIGRTMIN
>    #endif
>    #if defined(__SIGRTMAX) && !defined(_SIGRTMAX)
>    #define _SIGRTMAX __SIGRTMAX
>    #endif
> Is Linux's use of signal 32 for threading documented anywhere?
> I hate to hack in UPS features based purely on experiment.

It's not fixed to signal 32, but usually signal 32. glibc internally 
has an allocator for realtime signals and SIGRTMIN expands to an function
call that returns the first free signal (= 33 with linuxthreads). 
(that is why the preprocessor #ifs in obj_signal will likely not work
properly with glibc 2.2 btw) 
In POSIX that is all legal because you're supposed to use SIGRTMIN 
and not hardcode numbers but of course they didn't think of debuggers. 
You may need to call __libc_current_sigrtmin() to do the same or check
gdb source on how it handles that.It's not documented, but the interface 
will likely stay stable because it's part of the glibc ABI. 


This archive was generated by hypermail 2.1.4 : Wed Feb 13 2002 - 21:51:34 GMT