Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Re: JNI calls from inside UNIX signal handler

Reply
Thread Tools

Re: JNI calls from inside UNIX signal handler

 
 
Joseph Millar
Guest
Posts: n/a
 
      07-09-2003
On Tue, 08 Jul 2003 15:48:53 -0600, Marc Rochkind <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Marc Rochkind
Guest
Posts: n/a
 
      07-09-2003
On Wed, 09 Jul 2003 00:10:23 GMT, Joseph Millar
<(E-Mail Removed)> wrote:

> On Tue, 08 Jul 2003 15:48:53 -0600, Marc Rochkind <(E-Mail Removed)>
> 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


 
Reply With Quote
 
 
 
 
Joseph Millar
Guest
Posts: n/a
 
      07-09-2003
On Tue, 08 Jul 2003 18:35:33 -0600, Marc Rochkind <(E-Mail Removed)> 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
 
Reply With Quote
 
Marc Rochkind
Guest
Posts: n/a
 
      07-09-2003
On Wed, 09 Jul 2003 02:33:33 GMT, Joseph Millar
<(E-Mail Removed)> wrote:

> On Tue, 08 Jul 2003 18:35:33 -0600, Marc Rochkind <(E-Mail Removed)>
> 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

 
Reply With Quote
 
Bryan Castillo
Guest
Posts: n/a
 
      07-10-2003
Marc Rochkind <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> On Wed, 09 Jul 2003 02:33:33 GMT, Joseph Millar
> <(E-Mail Removed)> wrote:
>
> > On Tue, 08 Jul 2003 18:35:33 -0600, Marc Rochkind <(E-Mail Removed)>
> > 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

 
Reply With Quote
 
Marc Rochkind
Guest
Posts: n/a
 
      07-10-2003
On 10 Jul 2003 00:35:34 -0700, Bryan Castillo <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Throwing exceptions in a unix signal handler. Good idea? thagor2008@googlemail.com C++ 6 06-10-2008 10:10 AM
compile C programs with UNIX system calls (= Unix Programs??) jrefactors@hotmail.com C Programming 18 01-10-2005 03:35 AM
compile C programs with UNIX system calls (= Unix Programs??) jrefactors@hotmail.com C++ 12 01-10-2005 03:35 AM
Async-signal safe functions in signal handlers (unix) Michael Pronath Python 1 01-03-2005 01:10 PM
Re: JNI calls from inside UNIX signal handler Marc Rochkind Java 0 07-09-2003 03:44 PM



Advertisments