Adds a close() method to Compilation results#370
Conversation
This close method will allow file manager to be closed. Otherwise, during a normal test running lots of compilations, the java process might accumulate file descriptors. These open files are generally not a problem, but in the latest MacOS Ventura, the limit of open file descriptors is set to a low number and impossible to increase.
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
|
Is this an issue you've run into in practice with this? I haven't dug into the code much but it seems surprising to me that default file manager would hold open file descriptors given that Either way, I'm not sure this is the approach I'd prefer to take, in part because it would break a lot of code using this that's checked to ensure that |
|
Actually I think it's a lot simpler than I thought at first. There isn't any need for the file manager to still be open once the compilation has finished, so we can just ensure it's closed in |
…reates. Fixes #370 According to that PR, it sounds like not closing this can leak file descriptors. RELNOTES=Fixed `Compiler.compile` to ensure that it doesn't leak file descriptors. PiperOrigin-RevId: 570407877
|
Finally released in 0.22.0. |
This close method will allow file manager to be closed. Otherwise, during a normal test running lots of compilations, the java process might accumulate file descriptors. These open files are generally not a problem, but in the latest MacOS Ventura, the limit of open file descriptors is set to a low number and impossible to increase.