Re: [Classpathx-discuss] Java Signal Handling

[Matthew Johnson]

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.
>
> 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. 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.

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

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). 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.

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.

Matt

-- 
Matthew Johnson
http://www.matthew.ath.cx/