Re: RFR JDK-8005120

2013-01-17 Thread Chris Hegarty
ere. -Chris. Thanks! - Original Message - From:chris.hega...@oracle.com To:david.hol...@oracle.com Cc:alan.bate...@oracle.com,serviceability-...@openjdk.java.net,john.zavg...@oracle.com,net-dev@openjdk.java.net Sent: Thursday, December 20, 2012 7:41:07 AM GMT -05:00 US/Canada Eastern Subject: Re

Re: RFR JDK-8005120

2013-01-17 Thread John Zavgren
le.com Cc: alan.bate...@oracle.com, serviceability-...@openjdk.java.net, john.zavg...@oracle.com, net-dev@openjdk.java.net Sent: Thursday, December 20, 2012 7:41:07 AM GMT -05:00 US/Canada Eastern Subject: Re: RFR JDK-8005120 On 19/12/2012 20:52, David Holmes wrote: Real sense of deja-vu here. Didn't

Re: RFR JDK-8005120

2013-01-09 Thread Chris Hegarty
d.hol...@oracle.com Cc: alan.bate...@oracle.com, serviceability-...@openjdk.java.net, john.zavg...@oracle.com, net-dev@openjdk.java.net Sent: Thursday, December 20, 2012 7:41:07 AM GMT -05:00 US/Canada Eastern Subject: Re:

Re: RFR JDK-8005120

2013-01-08 Thread John Zavgren
jdk.java.net Sent: Thursday, December 20, 2012 7:41:07 AM GMT -05:00 US/Canada Eastern Subject: Re: RFR JDK-8005120 On 19/12/2012 20:52, David Holmes wrote: Real sense of deja-vu here. Didn't we go through this same thing with the HPI socket routines? Yes, and the networking native code t

Re: RFR JDK-8005120

2012-12-29 Thread Chris Hegarty
include "jvm_windows.h" #endif We could use a similar, but more simplistic, approach here. -Chris. Thanks! - Original Message - From: chris.hega...@oracle.com To: david.hol...@oracle.com Cc: alan.bate...@oracle.com, serviceability-...@openjdk.java.net, john.zavg...@oracle

Re: RFR JDK-8005120

2012-12-28 Thread John Zavgren
hris. Thanks! - Original Message - From: chris.hega...@oracle.com To: david.hol...@oracle.com Cc: alan.bate...@oracle.com, serviceability-...@openjdk.java.net, john.zavg...@oracle.com, net-dev@openjdk.java.net Sent: Thursday, December 20, 2012 7:41:07 AM GMT -05:00 US/Canada Eastern S

Re: RFR JDK-8005120

2012-12-27 Thread Dmitry Samersoff
t; #ifdef TARGET_OS_FAMILY_windows >> # include "jvm_windows.h" >> #endif >> >> We could use a similar, but more simplistic, approach here. >> >> -Chris. >> >>> Thanks! >>> >>> >>> - Original Message

Re: RFR JDK-8005120

2012-12-26 Thread Chris Hegarty
use a similar, but more simplistic, approach here. -Chris. Thanks! - Original Message - From: chris.hega...@oracle.com To: david.hol...@oracle.com Cc: alan.bate...@oracle.com, serviceability-...@openjdk.java.net, john.zavg...@oracle.com, net-dev@openjdk.java.net Sent: Thursday, De

Re: RFR JDK-8005120

2012-12-26 Thread John Zavgren
oach here. -Chris. Thanks! - Original Message - From: chris.hega...@oracle.com To: david.hol...@oracle.com Cc: alan.bate...@oracle.com, serviceability-...@openjdk.java.net, john.zavg...@oracle.com, net-dev@openjdk.java.net Sent: Thursday, December 20, 2012 7:41:07 AM GMT -05:00 US/Canada E

Re: RFR JDK-8005120

2012-12-21 Thread Chris Hegarty
..@oracle.com Cc: alan.bate...@oracle.com, serviceability-...@openjdk.java.net, john.zavg...@oracle.com, net-dev@openjdk.java.net Sent: Thursday, December 20, 2012 7:41:07 AM GMT -05:00 US/Canada Eastern Subject: Re: RFR JDK-8005120 On 19/12/2012 20:52, David Holmes wrote: Real sense of deja-vu here.

Re: RFR JDK-8005120

2012-12-21 Thread Dmitry Samersoff
including > > #ifdef TARGET_OS_FAMILY_windows > # include "jvm_windows.h" > #endif > > We could use a similar, but more simplistic, approach here. > > -Chris. > >> >> Thanks! >> >> >> - Original Message - >> F

Re: RFR JDK-8005120

2012-12-20 Thread John Zavgren
"jvm_windows.h" #endif We could use a similar, but more simplistic, approach here. -Chris. > > Thanks! > > > - Original Message - > From: chris.hega...@oracle.com > To: david.hol...@oracle.com > Cc: alan.bate...@oracle.com, serviceability-...@openjdk.ja

Re: RFR JDK-8005120

2012-12-20 Thread Dmitry Samersoff
> Thanks! > > > - Original Message - > From: chris.hega...@oracle.com > To: david.hol...@oracle.com > Cc: alan.bate...@oracle.com, serviceability-...@openjdk.java.net, > john.zavg...@oracle.com, net-dev@openjdk.java.net > Sent: Thursday, December 20, 2012 7:41:07 AM GMT -

Re: RFR JDK-8005120

2012-12-20 Thread Chris Hegarty
Original Message - From: chris.hega...@oracle.com To: david.hol...@oracle.com Cc: alan.bate...@oracle.com, serviceability-...@openjdk.java.net, john.zavg...@oracle.com, net-dev@openjdk.java.net Sent: Thursday, December 20, 2012 7:41:07 AM GMT -05:00 US/Canada Eastern Subject: Re: RFR JDK-8005120 On 19

Re: RFR JDK-8005120

2012-12-20 Thread John Zavgren
"socklen_t"? Thanks! - Original Message - From: chris.hega...@oracle.com To: david.hol...@oracle.com Cc: alan.bate...@oracle.com, serviceability-...@openjdk.java.net, john.zavg...@oracle.com, net-dev@openjdk.java.net Sent: Thursday, December 20, 2012 7:41:07 AM GMT -05:00 U

Re: RFR JDK-8005120

2012-12-20 Thread Chris Hegarty
On 19/12/2012 20:52, David Holmes wrote: Real sense of deja-vu here. Didn't we go through this same thing with the HPI socket routines? Yes, and the networking native code too. I think it is best to use socklen_t for the unix code. From what I can see making these changes, to use socklen_t, s

Re: RFR JDK-8005120

2012-12-19 Thread David Holmes
Real sense of deja-vu here. Didn't we go through this same thing with the HPI socket routines? Depending on the OS (and version?) we should be using socklen_t not int and not uint32_t. David On 20/12/2012 2:35 AM, Chris Hegarty wrote: John, I grabbed your patch, and with it I now see diffe

Re: RFR JDK-8005120

2012-12-19 Thread Dmitry Samersoff
Thanks! > John > - Original Message - > From: dmitry.samers...@oracle.com > To: john.zavg...@oracle.com > Cc: net-dev@openjdk.java.net > Sent: Wednesday, December 19, 2012 1:40:11 PM GMT -05:00 US/Canada Eastern > Subject: Re: RFR JDK-8005120 > > John, > > On 2012-1

Re: RFR JDK-8005120

2012-12-19 Thread John Zavgren
GMT -05:00 US/Canada Eastern Subject: Re: RFR JDK-8005120 John, On 2012-12-19 22:25, John Zavgren wrote: > Yes... I did consider that, but I didn't see any POSIX data types near the > code I was changing, so I decided to use a "brute force" data type instead. connect, recvfr

Re: RFR JDK-8005120

2012-12-19 Thread Dmitry Samersoff
-Dmitry > > Shall I make that change? > > John > - Original Message - > From: dmitry.samers...@oracle.com > To: john.zavg...@oracle.com > Cc: net-dev@openjdk.java.net > Sent: Wednesday, December 19, 2012 1:06:52 PM GMT -05:00 US/Canada Eastern > Subject: R

Re: RFR JDK-8005120

2012-12-19 Thread John Zavgren
com Cc: net-dev@openjdk.java.net Sent: Wednesday, December 19, 2012 1:06:52 PM GMT -05:00 US/Canada Eastern Subject: Re: RFR JDK-8005120 John, Did you consider using socklen_t instead of uint32_t and unsigned int (for namelen etc) ? -Dmitry On 2012-12-19 19:36, John Zavgren wrote: > Greetings: >

Re: RFR JDK-8005120

2012-12-19 Thread Dmitry Samersoff
John, Did you consider using socklen_t instead of uint32_t and unsigned int (for namelen etc) ? -Dmitry On 2012-12-19 19:36, John Zavgren wrote: > Greetings: > Please consider the following change to the two files: > src/share/transport/socket/sysSocket.h > src/solaris/transport/socket/socket_m

Re: RFR JDK-8005120

2012-12-19 Thread Chris Hegarty
John, I grabbed your patch, and with it I now see different warnings. ../../../../src/share/transport/socket/socketTransport.c: In function 'socketTransport_startListening': ../../../../src/share/transport/socket/socketTransport.c:310:40: warning: pointer targets in passing argument 3 of 'dbgs

Re: RFR JDK-8005120

2012-12-19 Thread Alan Bateman
John - this is the debugger socket transport so cc'ing the serviceability-dev list as that is where this code is maintained. On 19/12/2012 15:36, John Zavgren wrote: Greetings: Please consider the following change to the two files: src/share/transport/socket/sysSocket.h src/solaris/transport/

RFR JDK-8005120

2012-12-19 Thread John Zavgren
Greetings: Please consider the following change to the two files: src/share/transport/socket/sysSocket.h src/solaris/transport/socket/socket_md.c that eliminate compiler warnings that stem from the fact that the variables that the native code passes to various system calls were not declared corre