Re: [Classpathx-discuss] Java Signal Handling

[Andrew Haley]

Matthew Johnson writes:
 > On Mon, 13 Jun 2005, Andrew Haley wrote:
 > 
 > > gcj handles SEGV and FPE.
 > >
 > > It's difficult to do this in the general case.  In particular, it's
 > > not legal to return from many signal handlers, so it's necessary to do
 > > a longjmp(), which will destroy any local context.
 > >
 > > In the case where it is legal to continue after a signal has been,
 > > the idea of creating a new thread seems like sensible to do it.

Gosh, did I really write this?

I meant: In the case where it is legal to continue after a signal has
been delivered, creating a new thread seems like a sensible way to do
it.

 > > However, I'd be interested to see the application need for such a
 > > facility.  "An advantage of using Java signal handlers instead of
 > > native signal handlers is that your implementation can be completely
 > > in Java, keeping the application simple. Also, with Java signal
 > > handling you keep an object-oriented approach and refer to signals by
 > > name, making the code more readable than its C equivalent."  This
 > > seems like a very weak argument.
 > 
 > Having the JVM handle the signals rather than writing your own JNI code
 > that does sigaction() means that it can cope with threading,
 > particularly its own threading, and ensure that they don't interrupt any
 > of the JVMs threads when not expected.

Well, signals happen when they happen -- you have no control over
that.  Also, there's no portable way to determine which thread in a
multi-threaded process receives a signal.  If a JVM maps Java threads
to OS threads, you have no way to determine that either.

 > Also, I'm expecting my handler to be able to interface with my java
 > (re-read config, clean up sockets, checkpoint state and so
 > on)---things I can't easily do in C because I have to call other
 > java functions and refer to java objects and so on.

OK.

 > Comments on this by the authors of existing libraries:
 > 
 >    "Signals are the only area where Jtux couldn't implement the
 >    POSIX/SUS semantics exactly, because a signal mask can affect only
 >    the thread, not the whole process, and the Jtux program may be
 >    running on a JVM that's doing multi-threading internally. In other
 >    words, you can mask out, say, SIGTERM, but if that signal arrives and
 >    another thread has it unmasked, it will be delivered to that thread,
 >    and the attempt to mask it will be ineffective. There's no way around
 >    this, so you should consider Jtux's implementation of signals to be
 >    defective and you should not use Jtux to learn about UNIX signals.
 > 
 >    The other area where Jtux falls down is in returning a siginfo_t
 >    object to a real-time signal handler. It isn't legal for the Jtux
 >    implementation to build the Java object in the signal handler (the
 >    functions are not async signal safe), so it doesn't. Unfortunately,
 >    you'll find that your real-time signal handlers will always get a
 >    null reference to the siginfo_t object."
 > 
 >    -- http://www.basepath.com/aup/jtux/
 > 
 >    "It (trap.java) used to work on RH7.2 with IBM-1.1.8.  I think it
 >    broke when we upgraded glibc.  A lot of other java stuff also broke,
 >    unless we added "LD_ASSUME_KERNEL=2.2.5" to the environment.  I don't
 >    know why that works - for me it is voodoo.  But trap.java still
 >    doesn't work anymore on RH7.2 with IBM-1.1.8 (with upgraded glibc).
 >    Just checked, and it doesn't work with RH7.3 and IBM-1.1.8.
 > 
 >    Strangely, it *does* work on RH9 with IBM-1.1.8.  Your test program
 >    also works on RH9 with IBM-1.1.8.  So, the problem seems to be
 >    related to glibc more than the JVM."
 > 
 >    -- Stuart D. Gathman on why his library randomly stopped working


There are some pretty tight restrictions on exactly what signal
handlers may do.

 > I'm going to have to write callbacks into my C handler anyway, so why
 > force everyone to duplicate this? Its also the case that most java
 > programmers can't write C (or can't write it easily/safely/securely), or
 > don't want to have to bother with all of the *hassle* that JNI requires,
 > particularly in converting between java and C structures. (I can and
 > have written JNI, but doing so makes the coding, build system and
 > installation a lot more complicated, it also takes me a lot longer to
 > write C than Java, and I generally don't trust the code I have written
 > as much).

Can you give us some idea of what kind of signals you want to handle?  

 > One of the pieces of code I've written in the Sun Java signal
 > handler has to iterate over a thread safe list, get the threads
 > from them and then signal flags on them all. This is not something
 > I want to do in C.
 > 
 > Essentially I am considering writing my own library to do exactly this.
 > It will probably be flakey and cease to work randomly with JVM versions
 > if it is not integrated into the VM and it will not be a consistent API
 > that everyone else can use if its not in something like classpath.

Yes.

 > Does that seem like a reasonable explanation? Its something I have spent
 > 2 days trying to to get existing libraries to work and always coming up
 > to the fact that it doesn't work well unless it has JVM support.

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.

Andrew.