Re: [Classpathx-discuss] Java Signal Handling

[Andrew Haley]

David Brownell writes:
 > On Monday 13 June 2005 9:36 am, Andrew Haley wrote:
 > > 
 > > Well, signals happen when they happen -- you have no control over
 > > that.  Also, there's no portable way to determine which thread in a
 > > multi-threaded process receives a signal.  If a JVM maps Java threads
 > > to OS threads, you have no way to determine that either.
 > 
 > Well, I thought the general policy of how to mix signals and threads
 > was succinctly described as blocking signals in all threads, and
 > using sigwait() in one dedicated thread.  All other strategies being
 > error prone.

OK.  I think that ought to be possible in POSIX threads.

 > How that should map to Java runtimes, I won't speculate.  :)
 > 
 > > Because of the tight restrictions on what you can do in a signal
 > > handler, I can't immediately see anything better than creating a
 > > thread ahead of time and triggering that thread from the signal
 > > handler.  The thread, in turn, creates handler threads as required.
 > > That way, it doesn't matter what thread receives the signal.
 > 
 > Nah, it's better to just prevent signals from being async in
 > userspace in the first place.  Don't use signal handlers if
 > you're using threads.  Remember, even in single-threaded code
 > it's always been hard to make async signals work right.

I don't understand what you can do about this.  Some signals are
delivered asynchronously, and some are not.

 > If you think you need async signals, be a Real Man and write
 > hardware IRQ handlers that access chip registers.  (In Java!)
 > Let spinlocks be your friends, and don't pay attention to the
 > realtime people behind the curtain, telling you about how
 > IRQ handlers should run in threads too.

This doesn't seem to make any sense at all.  I thought the idea was to
make a portable API for signals, but we seem severely to have drifted.

Andrew.