hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Nauroth (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-573) Porting libhdfs to Windows
Date Thu, 31 Jul 2014 23:20:39 GMT

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

Chris Nauroth commented on HDFS-573:
------------------------------------

I guess I misread something on HADOOP-10388.  I thought I saw a nice clean init function in
the jni_helper.c over there.  I may have incorrectly assumed that this cascaded all the way
out to the client-facing API.  :-)

Thanks for sharing your experiences, Stephen.  Unfortunately, I think we'd have a hard time
incorporating those changes right now, given the compatibility concerns.

I suppose backwards-incompatible changes like this could be considered on the 3.x release
boundary.

BTW Colin, thanks for the code review.  The work so far has been aimed at a straight port,
warts and all, but I'm happy to roll in a few more small fixes for existing problems while
I'm in here.  I'll work on a v2 of the patch.

I have just one question though.  My initial inclination was to put {{TYPE_CHECKED_PRINTF_FORMAT}}
in platform.h as well.  However, I then backed that out and put the ifdef in exception.h,
because it has never been clear to me if exception.h is part of the public API.  Most of the
functions can't reasonably be considered public, because of the dependence on passing a {{JNIEnv}}.
 However, then there is {{getExceptionInfo}}.  As long as we agree that only hdfs.h is the
public API, and not exception.h, then I'll move {{TYPE_CHECKED_PRINTF_FORMAT}} back to platform.h.
 If client applications ever {{#include <exception.h>}}, then they'd also have the complexity
of selecting the correct platform.h, which would be undesirable.

> Porting libhdfs to Windows
> --------------------------
>
>                 Key: HDFS-573
>                 URL: https://issues.apache.org/jira/browse/HDFS-573
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: libhdfs
>         Environment: Windows, Visual Studio 2008
>            Reporter: Ziliang Guo
>            Assignee: Chris Nauroth
>         Attachments: HDFS-573.1.patch
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> The current C code in libhdfs is written using C99 conventions and also uses a few POSIX
specific functions such as hcreate, hsearch, and pthread mutex locks.  To compile it using
Visual Studio would require a conversion of the code in hdfsJniHelper.c and hdfs.c to C89
and replacement/reimplementation of the POSIX functions.  The code also uses the stdint.h
header, which is not part of the original C89, but there exists what appears to be a BSD licensed
reimplementation written to be compatible with MSVC floating around.  I have already done
the other necessary conversions, as well as created a simplistic hash bucket for use with
hcreate and hsearch and successfully built a DLL of libhdfs.  Further testing is needed to
see if it is usable by other programs to actually access hdfs, which will likely happen in
the next few weeks as the Condor Project continues with its file transfer work.
> In the process, I've removed a few what I believe are extraneous consts and also fixed
an incorrect array initialization where someone was attempting to initialize with something
like this: JavaVMOption options[noArgs]; where noArgs was being incremented in the code above.
 This was in the hdfsJniHelper.c file, in the getJNIEnv function.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message