[
https://issues.apache.org/jira/browse/HDFS-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14081637#comment-14081637
]
Colin Patrick McCabe commented on HDFS-573:
-------------------------------------------
bq. I am probably exposing my ignorance, so please forgive me. Are you saying
that using JNI automatically implies and requires thread support
Yep, that's what I'm saying.
bq. and that every JNI call is running on a thread?
Not every JNI call runs in a different thread, but many HDFS JNI calls
certainly do. For example, {{hdfsWrite}} uses {{DFSOutputStream}}, which ends
up starting a thread to write to the pipeline.
bq. From my very quick scan of the HADOOP-10388 branch, it looks like we'll be
providing a clearer initialization sequence there. libhdfs likely will need to
remain this way though.
I agree 100% that libhdfs should have had an "init" function that created some
kind of context we could pass around. But... we're going to try to keep the
existing API in HADOOP-10388. :P Sorry, it's just really nice to keep
compatibility where you can.
> 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)
