RFR: 8229872: (fs) Increase buffer size used with getmntent

[Vladimir Kempik]

Sorry, live, not leave, x2.

20 авг. 2019 г., в 22:46, Vladimir Kempik <vkempik at azul.com<mailto:vkempik at azul.com>> написал(а):

Hello
about L236, I really think I should not

linebuffer will leave throughtout app lifetime and will be realloced only when needed.  It’s kind of cache now, for use by getmntent_r.
if I free linebuffer and set it to NULL, then I will have to set maxlinelen to 0 as well, otherwise getline will fail.
This means the app will have to recalc maxline ( and do some reallocs to linebuffer) every time setmntent0 is called.

So I believe it’s better to let linebuffer leave, it’s not memory leak as we are tracking it and using it still.

Thanks, Vladimir.

20 авг. 2019 г., в 22:40, Brian Burkhalter <brian.burkhalter at oracle.com<mailto:brian.burkhalter at oracle.com>> написал(а):

Hello Vladimir,

L2: The newer copyright year should be changed to 2019.
L170: The line is too long.
L236: Before this line I think you should free() linebuffer.

Thanks,

Brian

On Aug 20, 2019, at 12:31 PM, Vladimir Kempik <vkempik at azul.com<mailto:vkempik at azul.com>> wrote:

after reading manpage for getline I think I have found some elegant solution - to let getline manage size of buffer.

Please review v2 of patch here http://cr.openjdk.java.net/~vkempik/8229872/webrev.02/

I’m still worried about syncing maxlinelen and linebuffer between Java_sun_nio_fs_LinuxNativeDispatcher_setmntent0 and Java_sun_nio_fs_LinuxNativeDispatcher_getmntent, if they are run from different threads.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190820/212690d8/attachment-0001.html>