Re: [Classpathx-discuss] Java Signal Handling

[Andrew Haley]

Matthew Johnson writes:
 > 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.

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.

Andrew.