[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Classpathx-discuss] Java Signal Handling

From: Andrew Haley
Subject: Re: [Classpathx-discuss] Java Signal Handling
Date: Mon, 13 Jun 2005 19:15:53 +0100

Matthew Johnson writes:
 > On Mon, 13 Jun 2005, Andrew Haley wrote:
 > > Can you give us some idea of what kind of signals you want to handle?
 > potentially? off the top of my head, INT, TERM, HUP, ABRT, USR1/2 definitely,
 > maybe things like WINCH and TSTP. Anything you would want to send
 > with a ctrl-something or kill -SOMETHING and aren't immediately fatal
 > like QUIT or KILL.
 > > I'm not arguing against creating a signal library -- it might be a
 > > good idea.  What I am saying is that you're going to be quite
 > > restricted as to what you can do legally.
 > >
 > > Because of the tight restrictions on what you can do in a signal
 > > handler, I can't immediately see anything better than creating a
 > > thread ahead of time and triggering that thread from the signal
 > > handler.  The thread, in turn, creates handler threads as required.
 > > That way, it doesn't matter what thread receives the signal.
 > This is a sensible way of doing it, but it would be nice to have some
 > way of doing with without needing to write any C yourself. 

OK, IMO it looks as though the API described on the IBM developerworks
page would be a good one to emulate.  It looks pleasingly simple.

The other approach of having a dedicated thread sitting in sigwait(),
would have the same API.

 > Also, signals which mean something really bad has happened and you
 > can't continue are less important to catch.

And pretty much impossible to handle in Java in most cases, I would


reply via email to

[Prev in Thread] Current Thread [Next in Thread]