[ 
https://issues.apache.org/jira/browse/HDFS-7018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14266484#comment-14266484
 ] 

Colin Patrick McCabe commented on HDFS-7018:
--------------------------------------------

Thanks, this looks a lot better.

The CMake changes look good.

{code}
64      static inline char *Strdup(const char *str) {
65          if (str == NULL) {
66              return NULL;
67          }
68      
69          int len = strlen(str);
70          char *retval = new char[len + 1];
71          memcpy(retval, str, len + 1);
72          return retval;
73      }
{code}

Please, let's just use the regular {{strdup}} provided by the system.  Then we 
also don't have to worry about "array delete" versus regular delete either.

{{struct hdfsFile_internal}}: we can simplify this a lot.  Rather than having 
setters, just have a constructor that takes an {{InputStream}}, and another one 
that takes an {{OutputStream}}.  We shouldn't need to alter the streams after 
the {{hdfsFile_internal}} object has been created.  Using a "union" here is 
overly complicated, and not really saving any space.  On a 64-bit machine the 
boolean you need to select which type the union pads the structure out to 16 
bytes anyway.  Just have a pointer to an input stream, and a pointer to an 
output stream, and the invariant that one of them is always {{null}}.

{code}
166     class DefaultConfig {
167     public:
168         DefaultConfig() : reportError(false) {
169             const char *env = getenv("LIBHDFS3_CONF");
170             std::string confPath = env ? env : "";
{code}
We should be looking at CLASSPATH and searching all those directories for XML 
files, so that we can be compatible with the existing libhdfs code.  Also, 
Hadoop configurations include multiple files, not just a single file.  You can 
look at how I did it in the HADOOP-10388 branch, which has a working 
implementation of this.  Alternately we could punt this to a follow-on JIRA.

{code}
224     struct hdfsBuilder {
225     public:
226         hdfsBuilder(const Config &conf) : conf(conf), port(0) {
227         }
228     
229         ~hdfsBuilder() {
230         }
231     
232     public:
{code}
We don't need line 232.  It's a bit confusing because I expected the line to 
say "private"

{{PARAMETER_ASSERT}}: this isn't what people usually mean by an {{assert}}.  
Usually an {{assert}} is something that only takes effect in debug builds, and 
is used to guard against programmer mistakes.   In contrast, this is validating 
a parameter passed in by the library user.  I would prefer not to have this 
macro at all since I think we ought to actually provide a detailed error 
message explaining what is wrong.  This macro will just fill in something like 
"invalid parameter" for EINVAL, which is not very informative.  I also think 
it's confusing to have "return" statements in macros... maybe we can do this 
occasionally, but only for a VERY good reason or in a unit test.

{code}
519         } catch (const std::bad_alloc &e) {
520             SetErrorMessage("Out of memory");
521             errno = ENOMEM;
522         } catch (...) {
523             SetErrorMessage("Unknown Error");
524             errno = EINTERNAL;
525         }
{code}

I see this repeated a lot in the code.  Why can't we use 
{{CreateStatusFromException}} to figure out exactly what is wrong, and derive 
the errno and error message from the Status object?

Since we're adopting the Google C\+\+ style, we will eventually remove the 
throw statements from other parts of the code, and then these "outer catch 
block" in the C API will be the only catch blocks left, and the only users of 
{{CreateStatusFromException}}, right?

{{hdfs.h}}: it's problematic to add stuff to this file until the other 
implementations support it.  We could get away with returning ENOTSUP from 
these functions.  But I think we need to discuss what some of them do... I'm 
not familiar with the "get delegation token", "free delegation token" APIs and 
we need to discuss what they do and if we want them, etc.  I think it's best to 
file a follow-on for that and leave it out for now.

> Implement C interface for libhdfs3
> ----------------------------------
>
>                 Key: HDFS-7018
>                 URL: https://issues.apache.org/jira/browse/HDFS-7018
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: hdfs-client
>            Reporter: Zhanwei Wang
>            Assignee: Zhanwei Wang
>         Attachments: HDFS-7018-pnative.002.patch, 
> HDFS-7018-pnative.003.patch, HDFS-7018.patch
>
>
> Implement C interface for libhdfs3



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to