You might want to check out the signal handling API in the Real-time Specification for Java - PosixSignalHandler. Basically you register what's known as an AsyncEventHandler to be released when the given signal occurs. It is a fairly simple API and doesn't really address some of the issues - for example, it makes it appear that you can register (and expect to have run) a handler for any signal. Nor does it distinguish between process-directed and thread-directed signals.
David Holmes > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > Matthew Johnson > Sent: Monday, 13 June 2005 10:52 PM > To: [email protected] > Subject: [Classpathx-discuss] Java Signal Handling > > > 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 > > > > _______________________________________________ > Classpath mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/classpath > _______________________________________________ Classpathx-discuss mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpathx-discuss
