RE: [Classpathx-discuss] Java Signal Handling

[David Holmes]

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: address@hidden
> [mailto:address@hidden Behalf Of
> Matthew Johnson
> Sent: Monday, 13 June 2005 10:52 PM
> To: address@hidden
> 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
> address@hidden
> http://lists.gnu.org/mailman/listinfo/classpathx-discuss
>
>
>
> _______________________________________________
> Classpath mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/classpath
>