Re: gcj: SignalListener, process pid, ...

[Erik Poupaert <erik dot poupaert at hurricanedev dot com>]

> This is tricky because an asynchronous signal handler can't do
> anything that might try to acquire a lock because it might block.
> That means that notify() couldn't be directly used.  I guess the
> handler could set a static variable somewhere.  That's probably
> adequate for this particular job.

The signals handled by the VM itself are the most tricky, as I understand it.
Especially -SIGTERM should probably be approached by using the VM shutdown hooks,
instead of handling it directly.

Otherwise, in relation to signals, I've come across postings complaining about
(p)threads on linux being processes really -- just sharing memory. On the one side it
looks most logical to me (this approach of threads being memory-sharing processes),
but on the other side I'd like to know what these posting actually would want it to
be (Is there a better way)? Could anybody knowledgeable give me his view on this
(privately)?

I'm also investigating http://www.bmsi.com/java/posix/package.html, who seem to know
what they're doing.

package posix;

/** Test out the signal handling classes.
 */

class trap implements SignalListener {
  trap() {
    Signal s = Signal.SIGINT;
    s.addSignalListener(this);
    s.setAction(Signal.SIG_EVT);
  }

  public void signalReceived(SignalEvent e) {
    Signal s = (Signal)e.getSource();
    System.err.println("Signal received");
  }

  public static void main(String[] argv) throws InterruptedException {
    new trap();
    Thread.sleep(10000);
  }
}

Looks good, doesn't it? If anybody is interested in the native compilation results,
let me know.

> Surely it's a simple matter to write native methods -- that's what
> JNI/CNI is for.  If this is a server for POSIX, who will care that
> it's not 100% Pure Java (TM) ?

It will be 100% pure GCJ (TM) though :-)