This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: [Fwd: Re: patch to ignore SIGPWR and SIGXCPU (used by pthreads)]
- From: Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>
- To: Per Bothner <per at bothner dot com>
- Cc: java at gcc dot gnu dot org
- Date: Mon, 21 Jan 2002 18:53:53 +1300
- Subject: Re: [Fwd: Re: patch to ignore SIGPWR and SIGXCPU (used by pthreads)]
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