Mladen, On 9/30/13 1:42 PM, Mladen Turk wrote: > On 09/30/2013 05:33 PM, Christopher Schultz wrote: >> >> I may need a little more guidance, since adding NULL-checks for >> everything is a little silly. Here is the function declaration in >> tcnative: >> >> TCN_IMPLEMENT_CALL(jint, Poll, poll)(TCN_STDARGS, jlong pollset, >> jlong timeout, jlongArray set, >> jboolean remove) >> >> >> Presumably, the pollset itself is non-null, but could all of the items >> in the pollset be null? >> > > APR does not check for parameter validity. Neither does TC native > in most cases (checks are actually leftovers from initial debugging). > It's up to java code to ensure params are valid, and thread safe if needed. > > I don't think there is nothing wrong with the native code. Using it is > where the majority of problems happen. Neither thread safety or param > checking should be part of native code. It's a thin low level wrapper. > Everything else should be done in java.
While I agree that the Java code should be responsible for providing good data to tcnative, the threat of a JVM crash should be enough of an incentive to do simple things like NULL-checking. r1518225 (granted, my commit) recently added NULL-checking for sockets which will hopefully reduce crashes when sockets are incorrectly reused under a number of conditions. I feel like the overhead is now (NULL-checks are super cheap) and the reward is high (fewer JVM crashes). Unless there is significant objection, I'd like to add such NULL checks to limit JVM crashes in cases where the Java code isn't absolutely perfect (with sincere apologies to all who manage the socket-management code in Tomcat). -chris
signature.asc
Description: OpenPGP digital signature
