[
https://issues.apache.org/jira/browse/HDFS-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14082430#comment-14082430
]
Stephen Bovy commented on HDFS-573:
-----------------------------------
Thanks Colin,
That is good news. The new pure native client looks very interesting. Our
app context is "c" although some parts of our app are also c++, so
we would need "c" binder/wrappers if this was written in c++.
On the topic of "threads" here is my thinking:
The lib-hdfs is like a skin-graft (or virus). It must adapt to the context of
its "host" without harming the host. If the "host" context is a "thread",
then of course lib-hdfs must survive in that context. but if the "host"
context, is not a thread, it should thrive with the host without unnecessary
thread-logic over-head.
If the "Java code" uses threads "under-the-covers" that is a black-box
non-issue as far as the host is concerned and should not germane to this
discussion.
I have added some backwards compatible code based on a flag to bypass the
thread-logic. The flag-default=threaded, that's why it is backwards
compatible. I have regression tested this with the host-thread-test app.
And it is working in my non-threaded app without any complaints.
I have also added an optional backwards-compatible lib-init function that
enables the usage of a static-global for the JVM pointer. This of course is
another "optimization" :)
I have also added a NEW function to hdfs.c to support "globs" :)
I would be happy to share some code-slices ( as food for thought ) thanks
> 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)
