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/ _______________________________________________ Classpathx-discuss mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpathx-discuss
