RFR: 8324668: JDWP process management needs more efficient file descriptor handling [v2]

Jaikiran Pai jpai at openjdk.org
Sat Jan 27 13:12:34 UTC 2024


On Sat, 27 Jan 2024 13:06:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 112:
>> 
>>> 110:     }
>>> 111: 
>>> 112:     closedir(dp);
>> 
>> Should this be:
>> 
>> `(void)close(fd);`
>> 
>> and 
>> 
>> `(void)closedir(dp);`
>> 
>> to show that we're ignoring the return value?
>> 
>> Since this area is pretty mysterious to deal with, should we consider checking whether `closedir()` actually returns am error, and at least be verbal and print a warning, as opposed to silently ignoring it?
>> 
>> Printing a warning, might help us diagnose any issue in the future?
>
>> Should this be:
>> (void)close(fd);
>> and
>> (void)closedir(dp);
>> to show that we're ignoring the return value?
> 
> Done. I've updated the PR to cast these calls to void.

>Since this area is pretty mysterious to deal with, should we consider checking whether closedir() actually returns am error, and at least be verbal and print a warning, as opposed to silently ignoring it?
Printing a warning, might help us diagnose any issue in the future?

I think printing a warning if closedir() fails may not be useful and may be misleading too. But your point about logging a warning in this area sounds reasonable. I think what we could log as a warning is if we fallback to the slow sequential close() approach if/when this optimal closeDescriptor() implementation fails. I've updated the PR with such a log message. Do you think that would be enough?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1468463361


More information about the serviceability-dev mailing list