tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_signal.c jk_user.c
Date Wed, 12 Jun 2002 14:55:08 GMT
On Wed, 12 Jun 2002, Mladen Turk wrote:

> Can you tell me what is the final goal of implementing the signals?

Well, my first 'itch' was the ability for a java program to send 
a SIGHUP to apache. Beeing able to receive a SIGHUP seemed interesting
too :-) 

> I ask you that because I'm working on a something simillar I hope, and
> more powerfull then standard signals offer. Basically it's a concept of
> apache server module hooks implemented on a module level, with the
> abillity to add the custom callback functions on the C and on the Java
> side.

The signals in jk are only for use by Java, and mostly for experimental
or specialized use. 

One of my goals is to explore using OS-specific features, which are not 
typically available to java programs ( because not portable ). I believe
this will allow better integration between java and the rest of the

Some may think that eventually all software in the world will be
written in java, and all OS-es will have exactly the same features
since nobody will be able to use specific features. Until this happens,
I think it would be nice to use the full power of the OS and 
integrate with the 'legacy' languages ( or C# will do it ) :-)

> On the other hand it would be platform independent. The only drawback is
> that the APR has to be enabled.

That would be great - and jkjni requires APR anyway. You may notice
the java class is called AprImpl, one of the goals is to expose all
APR features that are not available in java. 

Initially the class was just a jni wrapper to APR functions. Unfortunately
the JNI performance characteristics made this a bad solution, so now we
use all the tricks with buffer pinning to get around this. 

If your abstraction in APR will support signals ( as a particular case ),
then jk_signal will just go away. If not, I think it is valuable
to provide both - unix signals are one of the things that java lacks
and are usefull for integrating java with other applications. 


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message