[
https://issues.apache.org/jira/browse/HDFS-5541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831624#comment-13831624
]
Colin Patrick McCabe commented on HDFS-5541:
--------------------------------------------
bq. All variables must be declared at the begining of scope , and no (//)
comments allowed
I support the idea of declaring all variables at the beginning of the scope.
You can see that many of my patches have moved variables to this position. The
reason is more to avoid initialization errors than to conform to C89. I simply
am not aware of any compilers that can't handle this (gcc, LLVM, MSVC, etc. can
handle it).
However, there are no C compilers still in use that don't recognize '//'
comments. So let's not change things that don't need to be changed.
bq. 1) If threads are not used why do a thread attach ( when threads are not
used all the thread attach nonesense is a waste of time and a performance
killer )
That "nonsense" you're talking about is essential to how JNI works. Threads
need to be registered with the JVM. You can read more on Oracle's web site
here
http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html :
bq. The JNI interface pointer (JNIEnv) is valid only in the current thread.
Should another thread need to access the Java VM, it must first call
AttachCurrentThread() to attach itself to the VM and obtain a JNI interface
pointer. Once attached to the VM, a native thread works just like an ordinary
Java thread running inside a native method. The native thread remains attached
to the VM until it calls DetachCurrentThread() to detach itself.
bq. 2) The JVM init code should not be imbedded within the context of every
function call . The JVM init code should be in a stand-alone LIBINIT function
that is only invoked once. The JVM * and the JNI * should be global variables
for use when no threads are utilized.
Well, based on Oracle's documentation, you can see why the {{JNIEnv}} can't be
a global variable. Globals are unsuitable for libraries anyway, for reasons
you should already know. It would be nice to have an "init" function for
libhdfs, but it would break compatibility, something which is very important to
us. Maybe someday when we do a complete, compatibility-breaking rethink of the
API we can think about this.
bq. 4) Hash Table and Locking Why ????? When threads are used the hash table
locking is going to hurt perfromance . Why not use thread local storage for the
hash table,that way no locking is required either with or without threads.
If you use thread-local storage, you'll have to store {{num_threads}} times as
many class references.
bq. 5) FINALLY Windows Compatibility. Do not use posix features if they cannot
easilly be replaced on other platforms !!
Do you have any examples of this?
> LIBHDFS questions and performance suggestions
> ---------------------------------------------
>
> Key: HDFS-5541
> URL: https://issues.apache.org/jira/browse/HDFS-5541
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: hdfs-client
> Reporter: Stephen Bovy
> Priority: Minor
>
> Since libhdfs is a "client" interface", and esspecially because it is a "C"
> interface , it should be assumed that the code will be used accross many
> different platforms, and many different compilers.
> 1) The code should be cross platform ( no Linux extras )
> 2) The code should compile on standard c89 compilers, the
> >>> {least common denominator rule applies here} !! <<
> C code with "c" extension should follow the rules of the c standard
> All variables must be declared at the begining of scope , and no (//)
> comments allowed
> >> I just spent a week white-washing the code back to nornal C standards so
> >> that it could compile and build accross a wide range of platforms <<
> Now on-to performance questions
> 1) If threads are not used why do a thread attach ( when threads are not used
> all the thread attach nonesense is a waste of time and a performance killer )
> 2) The JVM init code should not be imbedded within the context of every
> function call . The JVM init code should be in a stand-alone LIBINIT
> function that is only invoked once. The JVM * and the JNI * should be
> global variables for use when no threads are utilized.
> 3) When threads are utilized the attach fucntion can use the GLOBAL jvm *
> created by the LIBINIT { WHICH IS INVOKED ONLY ONCE } and thus safely
> outside the scope of any LOOP that is using the functions
> 4) Hash Table and Locking Why ?????
> When threads are used the hash table locking is going to hurt perfromance .
> Why not use thread local storage for the hash table,that way no locking is
> required either with or without threads.
>
> 5) FINALLY Windows Compatibility
> Do not use posix features if they cannot easilly be replaced on other
> platforms !!
--
This message was sent by Atlassian JIRA
(v6.1#6144)
