I have just been discussing with the Kaffe team about handling Signals in Java and the suggested I propose something here.
The background to this is that I am trying to write Unix applications in Java because I like the language and hence I don't need portability (one of them uses libpcap and the other is X-specific); I was trying to find a way to handle signals because I want these applications to behave as closely as possible to standard Unix demons. Sun Java does not havean official way of handling signals but there are some undocumented classes to do it (see http://www-106.ibm.com/developerworks/ibm/library/i-signalhandling/). Obviously these are not implemented in FOSS JVMs because they are undocumented. There have been several attempts to write 3rd party libraries to do signal handling (http://www.bmsi.com/java/posix/package.html and http://www.basepath.com/aup/jtux/), but these are both broken. There are also more fundamental issues with using a JNI library in that they fail to address issues of which thread the signal is delivered to and how they are handled when they interrupt a JVM thread. Both of these things need handling in the JVM itself. The Kaffe people said that while this needs JVM support maintaining their own API (or trying to be complient with the Sun undocumented one) would not be sensible, so they said I should email this list to see whether a GNU classpath extension could be added with well-defined hooks for the JVMs to implement. The Java API used by the posix library at http://www.bmsi.com/java/posix/package.html looks sensible and a strategy for JVMs handling the signals suggested on #kaffe is for the JVM to catch the signal and then run the user-defined handler in a separate thread. I'd be interested in comments about this, particularly from VM writers as to how sensible this is te implement. As as aside, the other thing I would be interested in is having the JVM fork() and disown its TTY for proper daemon operation. Not sure if thats a VM or merely a library issue. Matt -- Matthew Johnson http://www.matthew.ath.cx/ _______________________________________________ Classpathx-discuss mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpathx-discuss
