[
https://issues.apache.org/jira/browse/HDFS-5541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831956#comment-13831956
]
Stephen Bovy commented on HDFS-5541:
------------------------------------
Thanks very much for tolerating my inept and sometimed ill informed questions.
>>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.
We support a wide range of platforms ( which is why compatibility is a hot
issue for me )
Some vendors stubornly adhere strictly to the letter of the law and tightly
follow standards ,
Here is a compiler that does not support (//) ( the ibm aix compiler ) >>>
[21:31:27]====================[21:31:27]= AIX 32-bit build
=[21:31:27]====================[21:31:27]clearmake -f makefile.twb -J 1
CLEARCASE_BLD_HOST_TYPE=otbe.aix-power TARGET_ARCH=aix-power.32
pdclibhdfs[21:31:37]Rebuilding "pdclibhdfs_all" on host
"esaix800.td.teradata.com" [21:31:41][21:31:41]======== Finished
"pdclibhdfs_all" on host "esaix800.td.teradata.com" ========[21:31:41] cd
"pdclibhdfs/src/" && clearmake -J 00001 -f makefile.twb
pdclibhdfs_all[21:31:41]clearmake[1]: Entering directory
`/vob/paralx/pdclibhdfs/src'[21:31:41]Rebuilding
"../../pdclibhdfs/aix-power.32/jni_helper.o" on host "esaix800.td.teradata.com"
[21:31:41][21:31:41]======== Finished
"../../pdclibhdfs/aix-power.32/jni_helper.o" on host "esaix800.td.teradata.com"
========[21:31:41] LIBPATH=../../../aix-power/usr/vac/lib xlc -qmaxmem=8192
-q32 -qnostdinc -F../../../aix-power/etc/otbe_vac.cfg -w -qhalt=e -c -O2
-qlanglvl=extended -I. -I../inc -I../../../java/aix-power.32/include
-I../../../java/aix-power/include -I../../../aix-power/usr/include
-DBUILDPRODUCTNAME="Teradata Parallel Transporter" -DBUILDPROJECT="Teradata PT
Hdfs Library" -DBUILDVERSION=15d.00.00.00T.D2D -DAIX -DTA_aix_power_32=1
-o../../pdclibhdfs/aix-power.32/jni_helper.o
jni_helper.c[21:31:41]"jni_helper.c", line 427.1: 1506-046 (S) Syntax
error.[21:31:41]*** Error code 1[21:31:41]clearmake: Error: Build script failed
for
"../../pdclibhdfs/aix-power.32/jni_helper.o"[21:31:41]========================================================[21:31:41][21:31:41]Aborting...[21:31:41]clearmake[1]:
Leaving directory `/vob/paralx/pdclibhdfs/src'[21:31:41]*** Error code
1[21:31:41]clearmake: Error: Build script failed for
"pdclibhdfs_all"[21:31:41]========================================================
On the thread issue ( I did not fully understand the code path )
I thought incorrectly that an application that did not use threads would
in-avertently be forced to invoke thread-attach.
But now I see that this is not the case, thanks
ON the windows front ( there is no support for the posix hash funcitons ) so
I had to scramble to find a replacement
I chose ut-hash ( for good or bad ) it was simple, easy and had a flexable
license.
I do have a question
Are the global class object pointers shared accross thread jni environements ?
I would have thought that everyting created with-in the context of one
jni-env would be local to that (env) ??
> 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)
