Re: (Round 2) RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

+1, looks fine to me also. Roger On 4/13/2016 6:46 AM, Thomas Stüfe wrote: Thanks Dmitry! On Wed, Apr 13, 2016 at 12:00 PM, Dmitry Samersoff > wrote: Thomas, Looks good for me! -Dmitry On 2016-04-13

Re: (Round 2) RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Thanks Dmitry! On Wed, Apr 13, 2016 at 12:00 PM, Dmitry Samersoff < dmitry.samers...@oracle.com> wrote: > Thomas, > > Looks good for me! > > -Dmitry > > > On 2016-04-13 12:12, Thomas Stüfe wrote: > > Hi Roger, Dmitry, > > > > May I ask you both to have a last look at this change before I commit?

Re: (Round 2) RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Thomas, Looks good for me! -Dmitry On 2016-04-13 12:12, Thomas Stüfe wrote: > Hi Roger, Dmitry, > > May I ask you both to have a last look at this change before I commit? > It took a while for this to go through our internal tests, hence the delay. > > New > version: >

Re: (Round 2) RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Hi Roger, Dmitry, May I ask you both to have a last look at this change before I commit? It took a while for this to go through our internal tests, hence the delay. New version: http://cr.openjdk.java.net/~stuefe/webrevs/8150460-linux_close-fdTable/webrev.03/webrev/ Delta to last version:

Re: (Round 2) RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Thank you Roger! On Fri, Mar 11, 2016 at 4:26 PM, Roger Riggs wrote: > Hi Thomas, > > When returning the address of the fdentry, the style using [fd] is > preferred over > the implicit pointer arithmetic (as it was in the previous version). > > Occurs in all 3 deltas: >

Re: (Round 2) RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Hi Thomas, When returning the address of the fdentry, the style using [fd] is preferred over the implicit pointer arithmetic (as it was in the previous version). Occurs in all 3 deltas: src/java.base/*/native/libnet/*_close.c: +result = fdTable + fd; and +result =

Re: (Round 2) RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Thank you Dmitry! I will fix the typo before comitting. Kind Regards, Thomas On Thu, Mar 10, 2016 at 9:19 AM, Dmitry Samersoff < dmitry.samers...@oracle.com> wrote: > Thomas, > > Looks good for me. But please wait for someone from core-libs team. > > PS: Could you also fix a typeo at 79, 51,

Re: (Round 2) RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Thomas, Looks good for me. But please wait for someone from core-libs team. PS: Could you also fix a typeo at 79, 51, 53? s/initialized/initialization/ 51 * Heap allocated during initialization - one entry per fd -Dmitry On 2016-03-10 10:59, Thomas Stüfe wrote: > Hi, > > may I have a

Re: (Round 2) RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Hi, may I have a review of this new iteration for this fix? Thank you! Thomas On Thu, Mar 3, 2016 at 5:26 PM, Thomas Stüfe wrote: > Hi all, > > https://bugs.openjdk.java.net/browse/JDK-8150460 > > thanks to all who took the time to review the first version of this

(Round 2) RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Hi all, https://bugs.openjdk.java.net/browse/JDK-8150460 thanks to all who took the time to review the first version of this fix! This is the new version: http://cr.openjdk.java.net/~stuefe/webrevs/8150460-linux_close-fdTable/webrev.02/webrev/ I reworked the fix, trying to add in all the