This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Andrew Cagney wrote:
> 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 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?
	--Per Bothner

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]