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

[Bryce McKinlay]

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.

regards

Bryce.

On Monday, January 21, 2002, at 06:42  PM, Per Bothner wrote:

> Anyone have any comments or background?
>
> My assumption is that the signals used by the gc have
> nothing to do with with whatever signals are used internally
> by the Solaris thread implementation.  What does (or should)
> boehm-gc use in the case of user-level threads on Solaris?
> -- 	--Per Bothner
> per@bothner.com   http://www.bothner.com/per/
>
> From: Andrew Cagney <ac131313@cygnus.com>
> Date: Mon Jan 21, 2002  01:48:32  PM Pacific/Auckland
> To: Per Bothner <per@bothner.com>
> Cc: gdb-patches@sources.redhat.com
> Subject: Re: patch to ignore SIGPWR and SIGXCPU (used by pthreads)
>
>
>> Index: infrun.c
>> ===================================================================
>> RCS file: /cvs/src/src/gdb/infrun.c,v
>> retrieving revision 1.50
>> diff -u -p -r1.50 infrun.c
>> --- infrun.c	2002/01/17 22:15:17	1.50
>> +++ infrun.c	2002/01/19 20:17:19
>> @@ -4298,6 +4298,12 @@ of the program stops.", &cmdlist);
>>    signal_stop[TARGET_SIGNAL_WINCH] = 0;
>>    signal_print[TARGET_SIGNAL_WINCH] = 0;
>>  +  /* These are used for pthread context switching, used by libgcj. */
>> +  signal_stop[TARGET_SIGNAL_PWR] = 0;
>> +  signal_print[TARGET_SIGNAL_PWR] = 0;
>> +  signal_stop[TARGET_SIGNAL_XCPU] = 0;
>> +  signal_print[TARGET_SIGNAL_XCPU] = 0;
>> +
>>    /* These signals are used internally by user-level thread
>>       implementations.  (See signal(5) on Solaris.)  Like the above
>>       signals, a healthy program receives and handles them as part of
>
>
> Per, can you please expand a little on the history of this choice of 
> signals?
>
>      SIGXCPU       terminate process    CPU time limit exceeded (see
>      SIGPWR        discard signal       power failure/restart
>
> I don't know that it is right to always silence/ignore these signals 
> when not all systems are using pthreads/libgcj.  This is even more 
> interesting given that just below we have:
>
>   /* These signals are used internally by user-level thread
>      implementations.  (See signal(5) on Solaris.)  Like the above
>      signals, a healthy program receives and handles them as part of
>      its normal operation.  */
>   signal_stop[TARGET_SIGNAL_LWP] = 0;
>   signal_print[TARGET_SIGNAL_LWP] = 0;
>   signal_stop[TARGET_SIGNAL_WAITING] = 0;
>   signal_print[TARGET_SIGNAL_WAITING] = 0;
>   signal_stop[TARGET_SIGNAL_CANCEL] = 0;
>   signal_print[TARGET_SIGNAL_CANCEL] = 0;
>
> puzzled,
>
> Andrew
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 2890 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java/attachments/20020120/cf69c8b5/attachment.bin>