[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-nio-dev
Subject: RFR(L): 8167295: Contribute further changes from SAP to native parts of libnet/libnio
From: "Langer, Christoph" <christoph.langer () sap ! com>
Date: 2016-10-06 15:43:37
Message-ID: 39b854eaa42a4417a401ff52633d3d1b () DEWDFE13DE11 ! global ! corp ! sap
[Download RAW message or body]
Hi,
I'm looking to contribute a few of our diffs in the network area to OpenJDK=
.
This is the bug: https://bugs.openjdk.java.net/browse/JDK-8167295
This is the webrev: http://cr.openjdk.java.net/~clanger/webrevs/8167295.0/
Besides minor cleanups, initializations and fixes, the main thing that I'm =
proposing is the unification of the union datatype SOCKADDR (unix) and SOCK=
ETADDRESS (windows).
I think the definition for all platforms should basically look like the fol=
lowing, of course depending on IPv6 support and the local datatypes:
typedef union {
struct sockaddr him;
struct sockaddr_in him4;
struct sockaddr_in6 him6;
} SOCKETADDRESS;
The type 'SOCKADDR' is already defined on Windows so we should consistently=
use 'SOCKETADDRESS'. This move would allow for better writing of shared co=
de dealing with sockaddr structures, which we do at SAP especially for some=
tracing code.
I don't know yet if it's a good idea to get rid of the definitions SOCKADDR=
_LEN resp. SOCKETADDRESS_LEN(x) and fully rely on sizeof(SOCKETADDRESS). I'=
ve done this in my webrev and it builds. But I'm not sure if especially som=
e Windows APIs would behave strangely if passed in a longer length values f=
or an AF_INET socket address. Maybe you have some comments on that point.
Apart from that, I think it is a good idea to get rid of 'NET_AllocSockaddr=
' as there is no need to malloc SOCKETADDRESS fields at the few places wher=
e it was used (libnio unix only). A stack variable would probably be better=
and less error prone. And the declaration of NET_Wait can move to the comm=
on net_util.h header as the function is available everywhere with the same =
signature.
Right now I'm just at a stage where my change builds on all platforms and I=
need to do some further testing. But I'm hoping for some early comments :)
Thanks and best regards
Christoph
[Attachment #3 (text/html)]
<html xmlns:v="urn:schemas-microsoft-com:vml" \
xmlns:o="urn:schemas-microsoft-com:office:office" \
xmlns:w="urn:schemas-microsoft-com:office:word" \
xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" \
xmlns="http://www.w3.org/TR/REC-html40"> <head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="DE" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">Hi,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">I’m looking to contribute a few of our \
diffs in the network area to OpenJDK.<o:p></o:p></span></p> <p \
class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p> <p \
class="MsoNormal"><span lang="EN-US">This is the bug: <a \
href="https://bugs.openjdk.java.net/browse/JDK-8167295"> \
https://bugs.openjdk.java.net/browse/JDK-8167295</a><o:p></o:p></span></p> <p \
class="MsoNormal"><span lang="EN-US">This is the webrev: <a \
href="http://cr.openjdk.java.net/~clanger/webrevs/8167295.0/"> \
http://cr.openjdk.java.net/~clanger/webrevs/8167295.0/</a><o:p></o:p></span></p> <p \
class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p> <p \
class="MsoNormal"><span lang="EN-US">Besides minor cleanups, initializations and \
fixes, the main thing that I’m proposing is the unification of the union \
datatype SOCKADDR (unix) and SOCKETADDRESS (windows).<o:p></o:p></span></p> <p \
class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p> <p \
class="MsoNormal"><span lang="EN-US">I think the definition for all platforms should \
basically look like the following, of course depending on IPv6 support and the local \
datatypes:<o:p></o:p></span></p> <p class="MsoNormal"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoNormal"><span \
lang="EN-US">typedef union {<o:p></o:p></span></p> <p class="MsoNormal"><span \
lang="EN-US"> struct sockaddr \
him;<o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-US"> \
struct sockaddr_in him4;<o:p></o:p></span></p> <p class="MsoNormal"><span \
lang="EN-US"> struct sockaddr_in6 him6;<o:p></o:p></span></p> <p \
class="MsoNormal"><span lang="EN-US">} SOCKETADDRESS;<o:p></o:p></span></p> <p \
class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p> <p \
class="MsoNormal"><span lang="EN-US">The type ‘SOCKADDR’ is already \
defined on Windows so we should consistently use ‘SOCKETADDRESS’. This \
move would allow for better writing of shared code dealing with sockaddr structures, \
which we do at SAP especially for some tracing code.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">I don’t know yet if it’s a good \
idea to get rid of the definitions </span><span lang="EN-US" \
style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#333333;background:white">SOCKADDR_LEN \
resp. SOCKETADDRESS_LEN(x) and fully rely on sizeof(SOCKETADDRESS). I’ve done \
this in my webrev and it builds. But I’m not sure if especially some Windows \
APIs would behave strangely if passed in a longer length values for an AF_INET socket \
address. Maybe you have some comments on that point.<o:p></o:p></span></p> <p \
class="MsoNormal"><span lang="EN-US" \
style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#333333;background:white"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#333333;background:white">Apart \
from that, I think it is a good idea to get rid of ‘NET_AllocSockaddr’ as \
there is no need to malloc SOCKETADDRESS fields at the few places where it was used \
(libnio unix only). A stack variable would probably be better and less error prone. \
And the declaration of NET_Wait can move to the common net_util.h header as the \
function is available everywhere with the same signature.</span><span \
lang="EN-US"><o:p></o:p></span></p> <p class="MsoNormal"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoNormal"><span \
lang="EN-US">Right now I’m just at a stage where my change builds on all \
platforms and I need to do some further testing. But I’m hoping for some early \
comments </span><span lang="EN-US" style="font-family:Wingdings">J</span><span \
lang="EN-US"><o:p></o:p></span></p> <p class="MsoNormal"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoNormal"><span \
lang="EN-US">Thanks and best regards<o:p></o:p></span></p> <p class="MsoNormal"><span \
lang="EN-US">Christoph<o:p></o:p></span></p> <p class="MsoNormal"><span \
lang="EN-US"><o:p> </o:p></span></p> </div>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic