[Fwd: Re: patch to ignore SIGPWR and SIGXCPU (used by pthread s)]

Boehm, Hans hans_boehm@hp.com
Mon Jan 21 10:23:00 GMT 2002

The collector has used real-time signals on a number of platforms for a
while.  I think you can change it to do so on linux by setting macros
SIG_SUSPEND and SIG_THR_RESTART to the appropriate signal numbers.  Thus
changing it is trivial.

The most difficult issue seems to be that there is no portable mechanism,
that I know of, anyway, for allocating signal numbers.  Thus any change to
the defaults are likely to break some code that already happens to use the
same signals.  If there is a way to do the allocation more correctly, we
should use that.

In spite of this, I would favor changing the Linux default, and I would
rather use the same signal numbers in all cases.  (I vote for
_SIGRTMIN+{5,6}, since those are already used on some platforms.)


> -----Original Message-----
> From: Per Bothner [mailto:per@bothner.com]
> Sent: Monday, January 21, 2002 8:51 AM
> To: Bryce McKinlay
> Cc: java@gcc.gnu.org
> Subject: Re: [Fwd: Re: patch to ignore SIGPWR and SIGXCPU (used by
> pthreads)]
> Bryce McKinlay wrote:
> > Ideally the GC should just use "real-time" signals for the thread 
> > suspend/resume on systems which support them. GDB won't 
> stop on an RT 
> > signal. Linux didn't support them until a few years ago but 
> it should be 
> > easy enough to do a configure test instead of the "# if 
> > defined(GC_HPUX_THREADS) || defined(GC_OSF1_THREADS)" that 
> is currently 
> > done in boehm-gc/linux_threads.c.
> Is this easy to fix?  I have no idea how to use "real-time signals".
> I really would like to fix either the Java runtime or gdb so people
> debugging Java programs don't have to issue 'handle' commands.  That
> is just not acceptable.
> -- 
> 	--Per Bothner
> per@bothner.com   http://www.bothner.com/per/

More information about the Java mailing list