Re: [Classpathx-discuss] Java Signal Handling

[David Brownell]

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.

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.

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.

- Dave