New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
jplephem should cleanup resources better #24
Comments
Thanks for the kudos, that was very nice of you to include! :) The library is designed to open the file exactly once, when
—doesn't have to do the expensive memory map operation twice but can keep using the same memory map over again. How many segments does your kernel have? What is the full traceback, so that we can see which line of code is erroring? That might tell us which resource is running out on your system. |
|
|
Sorry, this number can vary - restricting it to the first 200 seems to always run. Getting closer to 256 starts to get me more and more failures (i.e. there is some variability in when it actually fails) |
Wow — 343 segments! The library's current approach, of only mmap'ing the segments that the user tries to access, is designed to minimize the amount of the process's RAM image that's in use by the library in the case where someone only needs to use a few segements. On 32-bit machines and kernels with only a few huge segments, the trade-off seemed important. But with modern 64-bit address spaces it probably would make more sense to simply mmap() the entire kernel, instead of making a separate map for each segment — and, of course, that approach would prevent you from running out of file descriptors in the case where the number of segments is large. I wonder if I should switch the default behavior for everyone, or make the new behavior an option? I'm thinking of kernels like |
I've just released version 2.8, which should hopefully fix your problem. I'm going to close the issue, but feel free to re-open if you run into this problem again! |
Use case
I have a file (
ast343de430.bsp
) containing about 300 bodies. I want to plot the positions of all the bodies at one given instant of time.Problem
When I use the following code
I get:
OSError: [Errno 24] Too many open files
Expected behavior
Each call to
kernel[p].compute(2457061.5)
should clean up such that we don't run into this issue.Kudos
BTW, library writers often just get gripes from users, so I'd like to point out here that I really like
jplephem
and it is my go to Python solution for all things SPK related. Thank you for all the effort you have put into it!The text was updated successfully, but these errors were encountered: