«

On Tue, 08 Jul 2003 15:48:53 -0600, Marc Rochkind <> wrote:
[snip!]
> Has anyone had success with this particular use of JNI? I'm especially
> looking for first hand experience with this. The conventional opinion would
> be, of course, "No way!!!!"
>
> (It's on an Intel Solaris box running Java 1.3.)
[snip!]

In general, I have to agree, it's not such a good idea, for several
reasons. First and foremost, if your native code is setting signal
handlers, it's likely overwriting the signal handers that the JVM
has installed and which it needs in order to behave properly.
Secondly, your signal handling code is calling JNI routines which may
themselves generate signals, thus resulting in a recursion loop or
confusion at best. If you ask me, you're asking for big trouble.
But if you're careful and keep what you need to do at a minimum it
should work, but you will need libjsig.so to make it work properly
in all cases.

Prior to 1.4, libjsig.so was only available at special request from
Sun. Starting in 1.4, it's part of the core. What it does is basically
front end the sigaction() and like api's and protects and chains the
JVM's signal handers from overwriting. What you do is link your native
code with libjsig (or LD_PRELOAD it), and whenever you call sigaction
or one of it's cousins, libjsig will act as traffic cop and allow
your handlers to coexist with the JVM's. It's not a perfect solution,
but then signal handlers aren't either. I would recommend going to
to JDK 1.4.2 on Solaris if you can. If you have to stay on 1.3.1,
my understanding is the libjsig in 1.4 will still work, but I have
never verified that. See the libjsig documentation in the JDK docs
for more info.

Good luck.

--Joe

On Wed, 09 Jul 2003 00:10:23 GMT, Joseph Millar
<> wrote:

> On Tue, 08 Jul 2003 15:48:53 -0600, Marc Rochkind <>
> wrote:
> [snip!]
>> Has anyone had success with this particular use of JNI? I'm especially
>> looking for first hand experience with this. The conventional opinion
>> would be, of course, "No way!!!!"
>>
>> (It's on an Intel Solaris box running Java 1.3.)
> [snip!]
>
> In general, I have to agree, it's not such a good idea, for several
> reasons. First and foremost, if your native code is setting signal
> handlers, it's likely overwriting the signal handers that the JVM
> has installed and which it needs in order to behave properly.

It's easy to generate a list (from JNI code) of signals that the JVM has
neither arranged to catch or ignore. I'm sticking with those for my tests.
(Like, say, SIGRTMIN.)

> Secondly, your signal handling code is calling JNI routines which may
> themselves generate signals, thus resulting in a recursion loop or
> confusion at best. If you ask me, you're asking for big trouble.

Must be... or else I have received it wihtout asking! But, seriously,
trouble is what I want. I'm exploring the JNI environment.

> But if you're careful and keep what you need to do at a minimum it
> should work, but you will need libjsig.so to make it work properly
> in all cases.

Thanks a million for this! I never would have otherwise come across it.
Nothing you've said implies that this library helps me with my lost-class
problem, but we shall see... I'm hopeful!

[snip]

--Marc

On Tue, 08 Jul 2003 18:35:33 -0600, Marc Rochkind <> wrote:
> Must be... or else I have received it wihtout asking! But, seriously,
> trouble is what I want. I'm exploring the JNI environment.

You want trouble? Steal SIGSEGV and try anything in that
would normally generate a NullPointerException.


> Thanks a million for this! I never would have otherwise come across it.
> Nothing you've said implies that this library helps me with my lost-class
> problem, but we shall see... I'm hopeful!

Not sure what the issue is there, but if you use libjsig,
the problem just might disappear if the issue is signal
based. Try it and let us know.

--Joe

On Wed, 09 Jul 2003 02:33:33 GMT, Joseph Millar
<> wrote:

> On Tue, 08 Jul 2003 18:35:33 -0600, Marc Rochkind <>
> wrote:
>> Must be... or else I have received it wihtout asking! But,
>> seriously, trouble is what I want. I'm exploring the JNI environment.
>
> You want trouble? Steal SIGSEGV and try anything in that
> would normally generate a NullPointerException.
>
>
>> Thanks a million for this! I never would have otherwise come across it.
>> Nothing you've said implies that this library helps me with my lost-
>> class problem, but we shall see... I'm hopeful!
>
> Not sure what the issue is there, but if you use libjsig,
> the problem just might disappear if the issue is signal
> based. Try it and let us know.
>
> --Joe
>

Went to 1.4.2 and the immediate problem (not finding the class) went away
and stayed away, without doing anything with libjsig, as I don't think this
was a signal-chaining issue.
I went ahead and added libjsig anyway.

I have other weirdnesses, which I don't think have any solution, when I
call NewObject from within the signal handler. It seems to work, but then
later (much later) the program exhibits other strange behavior. This is
probaly because NewObject (and many other calls I'm making) aren't async
signal safe. I suspected this, but wanted to see what would happen.

--Marc

Marc Rochkind <> wrote in message news:<>...
> On Wed, 09 Jul 2003 02:33:33 GMT, Joseph Millar
> <> wrote:
>
> > On Tue, 08 Jul 2003 18:35:33 -0600, Marc Rochkind <>
> > wrote:
> >> Must be... or else I have received it wihtout asking! But,
> >> seriously, trouble is what I want. I'm exploring the JNI environment.
> >
> > You want trouble? Steal SIGSEGV and try anything in that
> > would normally generate a NullPointerException.
> >
> >
> >> Thanks a million for this! I never would have otherwise come across it.
> >> Nothing you've said implies that this library helps me with my lost-
> >> class problem, but we shall see... I'm hopeful!
> >
> > Not sure what the issue is there, but if you use libjsig,
> > the problem just might disappear if the issue is signal
> > based. Try it and let us know.
> >
> > --Joe
> >
>
> Went to 1.4.2 and the immediate problem (not finding the class) went away
> and stayed away, without doing anything with libjsig, as I don't think this
> was a signal-chaining issue.
> I went ahead and added libjsig anyway.
>
> I have other weirdnesses, which I don't think have any solution, when I
> call NewObject from within the signal handler. It seems to work, but then
> later (much later) the program exhibits other strange behavior. This is
> probaly because NewObject (and many other calls I'm making) aren't async
> signal safe. I suspected this, but wanted to see what would happen.
>

Instead of trying to execute java code in a signal handler
could you get a similar effect by marking signals as having occured
with C code, and then using a thread (mostly java) that monitors
the signal marking and calls back some other java object (from a thread,
not a signal handler)?

> --Marc

On 10 Jul 2003 00:35:34 -0700, Bryan Castillo <> wrote:


[snip]

>
> Instead of trying to execute java code in a signal handler
> could you get a similar effect by marking signals as having occured
> with C code, and then using a thread (mostly java) that monitors
> the signal marking and calls back some other java object (from a thread,
> not a signal handler)?
>

I would love to...

But, there are cases -- a signal caused by the arrival of a message on a
POSIX message queue, for example -- where information in a siginfo_t
structure is passed to the signal handler. This information needs to be
captured somehow and passed, eventually, to the Java program.

Less generally, what I'm trying to do is construct a package that allows
students learning POSIX/SUS to write programs in Java, Jython, or, perhaps,
even BeanShell. Alas, is seems that signals will have to be omitted from
the lab, although it seems that most everything else in POSIX/SUS is
working well (even shared memory).

--Marc