[
https://issues.apache.org/jira/browse/HDFS-5541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13841932#comment-13841932
]
Chris Nauroth commented on HDFS-5541:
-------------------------------------
bq. Great proposals, Chris. I agree with all of them. I guess the next step is
to file the follow-up JIRAs.
Thanks, Colin. I plan to file these later today and close out HDFS-5541.
bq. As this is an Apache project, I think these discussions belong in the open.
Stephen just wanted to know when I, personally, would have availability to put
significant effort into this. (Answer: probably not until January.) I promise
that nothing relevant has been withheld from the discussion here on Apache.
Stephen, feel free to email me directly for similar questions in the future.
bq. Another thing I would kind of like to see is the Windows build using CMake.
Part of the rationale for checking in the vcxproj files was to provide a good
dev experience for a typical Windows developer using Visual Studio. When I had
looked at using CMake, it seemed we would have to compromise on that. If we
revisit this, then I'd like to get feedback from a Visual Studio user. (I
don't use it myself.) We definitely have a maintenance cost right now due to
duplicated build logic, particularly around optional things like Snappy support.
> 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
> Attachments: pdclibhdfs.zip
>
>
> 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)
