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

Sun Jan 20 22:07:00 GMT 2002

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>