Re: [Classpathx-discuss] Java Signal Handling

[David Brownell]

On Monday 13 June 2005 10:11 am, Andrew Haley wrote:
> David Brownell writes:
>  > On Monday 13 June 2005 9:36 am, Andrew Haley wrote:
>  > > 
>  > 
>  > 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.

Exactly.  Though without POSIX threads ... unclear.  That's why
async signals are a recurring problem in design of all kinds of
portable runtime, not just Java.


>  > 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.

Before you spawn the first thread, block all async signals; the
sync ones (illegal instruction etc) should keep their context.
Then later you can sigwait() for those async signals; only your
thread will receive them.

At least, that's how I recall doing it... I used to do a lot more
POSIX threading, nowadays I have to look such stuff up each time
I create a new threaded userspace program.


>  > 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.

Not that severely; the original idea of async signals was to
emulate hardware IRQ handlers.  But they never did a good job,
and were error prone.  Look at the generations of signal handling
API in UNIX ... more than three, and it's still not obvious how
to do it right (for most people).

All the reasons that model works poorly in C (outside an OS kernel)
apply in spades to an environment like Java.  Did I forget the darn
smiley again?  OK, here's one:  :)

If you step away from Java details for a moment, and look at
the big picture, the very _question_ of "portable signals"
looks rather dubious.  Best to move away from that notion, and
to look at how other complex systems software projects have
dealt with such problems.  One way to do that is to look at
the original notion -- hardware IRQs.  It's interesting that
so many real-time folk don't want most programmers to ever work
with async signals either.

- Dave