-
Notifications
You must be signed in to change notification settings - Fork 163
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
Signal an error when internal file descriptor limit is reached (at most 256 files can be open at the same time) #5146
Conversation
Fine by me, though better would of course be if we took automatically care of closing streams whenever possible. I see two ways to achieve that:
Using finalizers requires work in the kernel: basically, whenever a stream holding a file descriptor is garbage collected, we could close its file descriptor (to avoid closing the same fd twice, We could use a "weak pointer object": we already have
That does of course not make your patch redundant, but it would reduce the impact of people forgetting to use |
I have relaxed the |
Could you perhaps add a test? Something like this should work, I think: gap> streams:=[];;
gap> for i in [1..300] do
> Add(streams, OutputTextFile(Concatenation("test",String(i)),false));
> od;;
Error, ...
gap> Perform(streams, CloseStream); |
and add corresponding notes to the documentation
Done! |
and add corresponding notes to the documentation
Rationale: I guess most code does not handle the case that
InputTextFile
orOutputTextFile
returnsfail
properly, or just prints a generic error message like "Could not open file", which is not very helpful. Thus, making this error explicit significantly simplifies debugging. If one really wants to handle this gracefully, one can look atInputTextFileStillOpen
andOutputTextFileStillOpen
to detect if opening a new file would reach the descriptor limit.Text for release notes
none