hpi::get_host_by_name() / hpi::get_host_by_addr() not defined for Linux/Solaris
Thomas.Rodriguez at Sun.COM
Mon Sep 15 13:57:19 PDT 2008
I vaguely remember from the early days that the HPI network interface
was needed because a posix style network API wasn't available on all
versions of windows, so we had to use winsock directly. There's also
some overly complex layering going on where the JVM imports some
interfaces and then exports back to libjava/libnet through the JVM_
functions. We only export the network related JVM_ functions on
windows since the other platforms use posix directly. The hpi class
in hotspot declares all the network functions but only provides
definitions on windows, presumably because they weren't needed on
other platforms. So basically it's a bit of a historical mess.
Additionally the HPI layer has it's own semantics related to
interruptible I/O which can make it a little challenging to use them
and also makes it's less than ideal as a bottom level interface inside
hotspot. It should be easy to fix the ostream code by providing a
platform definition of the needed hpi socket functions, either by
actually calling into the hpi or simply providing platform dependent
direct calls to the appropriate posix interface. Even if the HPI goes
away as an external lib, I suspect at least some of the code will have
to live in some place we can access it, unless we can stop using
winsock on windows and use sockets directly. So basically I think
using the hpi internally to hotspot for writing socket code would be
fine until a better strategy comes along.
On Sep 15, 2008, at 8:35 AM, Volker Simonis wrote:
> is there a specific reason why some of the hpi-methods declared in
> "src/share/vm/runtime/hpi.hpp" are not defined for Linux/Solaris (e.g.
> This leads to ugly code like:
> #ifdef _WINDOWS
> struct hostent* host = hpi::get_host_by_name((char*)ip);
> struct hostent* host = gethostbyname(ip);
> in "src/share/vm/utilities/ostream.cpp".
> What's the general advice if one needs to use for example networking
> functions in HotSpot coding. Should the hpi-methods still be used? I
> remember sombody on this list (Keith???) was saying they'll get
> obsolete some day?
More information about the hotspot-runtime-dev