[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
imagine.
Andrew.
Re: [Classpathx-discuss] Java Signal Handling, shudo, 2005/06/13
RE: [Classpathx-discuss] Java Signal Handling, David Holmes, 2005/06/13