This is the mail archive of the
mailing list for the GDB project.
Re: patch to ignore SIGPWR and SIGXCPU (used by pthreads)
- From: Per Bothner <per at bothner dot com>
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Sun, 20 Jan 2002 21:51:39 -0800
- Subject: Re: patch to ignore SIGPWR and SIGXCPU (used by pthreads)
- References: <3C49D806.email@example.com> <3C4B6560.firstname.lastname@example.org>
Andrew Cagney wrote:
> Per, can you please expand a little on the history of this choice of
> SIGXCPU terminate process CPU time limit exceeded (see
> SIGPWR discard signal power failure/restart
I forwarded your message to the java mailing list. But my assumption
is - what does it matter? At least when using linux-threads, we do use
these signals. As I understand it, linux-threads uses kernel support
and does not uses signals. However, the garbage collector needs to be
able to stop and re-start all threads when doing a collection. It does
this using signals, at least under linux-threads. This has nothing to
do with the Solaris user-leel threads implementation, and is a
completely orthoginal issue.
> I don't know that it is right to always silence/ignore these signals
> when not all systems are using pthreads/libgcj.
Why not? What does it hurt to (by default) just pass them to the
inferior? Having gdb stop inconveniences (and confuses) everybody who
uses gcj. Having gdb silently pass the signals to the application
inconveniences/confuses - who?