[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Classpathx-discuss] Java Signal Handling

From: David Brownell
Subject: Re: [Classpathx-discuss] Java Signal Handling
Date: Mon, 13 Jun 2005 09:58:38 -0700
User-agent: KMail/1.7.1

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]