Re: Handling of siginfo, Java compatability with IBM jdk

The Linuxthreads implementation of signal handlers is not posix 
complaint.  The reason for that were in part the same reason that IBM is 
creating ngph.  Using sigwait on linux, as recommended by the thread 
books I have does not work.

I solved the problem by writing a C++ class to manage signals.  On 
Solaris it uses sigwait.  On linux: I set the signal mask and handler up 
the way I want. I record the TID of a single thread that I want to 
deliver the signals.  Then I park it on a semaphore, and start the rest 
of the application.

When the signals are delivered (by every thread in the process for most 
signals) I check the TID of each thread coming it.  If it matches the 
one I want to use (the one parked on the semaphore prior to being 
interrupted.) I record the signal and signal the semaphore.  The thread 
then returns back to its semaphore to find it has been signaled. (by 
itself, but that doesn't matter.)  It then does my desired work the same 
as the solaris thread that was parked on sigwait did.

Corey Minyard wrote:

> I thought I would ask a question and answer a question...
> 
> How does NGPT handle siginfo?  It seems (from looking at the code, so I 
> could have missed something) that currently the information in the 
> siginfo structure is wrong because the signal is resent from another 
> process.  I would thing that tkill() should take a siginfo structure and 
> be allowed to set the data.
> 
> This is actually related to the answer below.  I have a threads package 
> I have been working on designed for reliability.  It runs in 
> LinuxThreads compatability mode (which handles signals just like 
> LinuxThreads) and in POSIX compliant mode (which handles signals like 
> POSIX says to).  I have some Java implementations running in 
> LinuxThreads compatability mode, but none work in POSIX compliant mode. 
>  I suspect that it has something to do with the siginfo not being 
> correct, or perhaps that the Java implementation is directly calling 
> kill().  But either way, I would like the siginfo stuff to be right, and 
> I think a change to tkill is necessary to do it.
> 
> The answer to the question below is that it was VERY hard to get my 1:1 
> threads package to work under Java, even in LinuxThreads compliant mode. 
>  The JVMs do bizzare things, and they rely on undocumented behaviour 
> inside LinuxThreads, and I believe they rely on a 1:1 threads mapping. 
>  (Why can't they just trust the threads package to do the right thing? 
>  Why do they have to do their own things with the stack?)  This is both 
> Blackdown's and IBM's JDK.  It is going to be VERY VERY hard to get NGPT 
> to run the existing JDKs.  It may not even be doable.  When someone gets 
> there, I can look through my logs and see the problems I ran into and 
> advise, if necessary.  But IMHO, someone needs to fix the JDKs.
> 
> -Corey
> 



-- 
Andrew Lundgren
[email protected]
Senior Software Engineer