<abu[7]>
Great! I added only the findl missing thing, stopping with (co 'a)
<abu[7]>
I think I never used that in applications, only interactively
seninha has joined #picolisp
seninha has quit [Remote host closed the connection]
seninha has joined #picolisp
pablo_escoberg has joined #picolisp
<fbytez>
abu[7], I don't know if you took a look at the paste but the reason I'm suggesting there may be a leak is that the descriptors are not being closed when an error occurs.
pablo_escoberg has quit [Quit: Client closed]
<abu[7]>
Hmm, yes, I looked, and saw that you started many children and thus run into a lack of file descriptors. This is all right.
<abu[7]>
FDs are not closed automaticallly, yes
<abu[7]>
(in .. (quit ...] will close after leaving the error handler
<abu[7]>
but (open "file") -> fd will not
<abu[7]>
same with forks
<abu[7]>
The children are still running
<fbytez>
I'm not sure we're understanding each other. Are you saying that you consider it to be correct behaviour that the parent opens file descriptors and does not close them when failing to create the child?
<abu[7]>
I see, you mean the ones created just befire the error
<abu[7]>
*before
<abu[7]>
1022 in your case
<abu[7]>
I think I did not consider worth the effort
<abu[7]>
you are right that 'forkLisp' could clean up all FDs it created up to that point
<abu[7]>
Some additional code
<abu[7]>
But this error is fatal anyway, it does not make much sense to continue with the application here
<abu[7]>
So I do not want to blow up the code here
<abu[7]>
*correct* would be to clean up. yes
<abu[7]>
It is not just the FDs, also all the other data structures
<fbytez>
Why do you consider it fatal? It's certainly not in my example; other children dying would free up resources.
<abu[7]>
It is fatal, because of not enough system resources
<abu[7]>
Same with stack overflow
<abu[7]>
or out of memory
<abu[7]>
The application needs to be rewritten to use less resources, or system limits need to be increased
<abu[7]>
Your example is in the REPL
<abu[7]>
a production app, which is not started with a TTY, terminates on such an error
<abu[7]>
(or on any error to be exact)
<abu[7]>
So this cleanup code is never needed, just blows up forkLisp() a lot
<abu[7]>
As I said, if your app does 'open' or 'connect' explicitly, and has no 'finally', you also run into a FD leak
<abu[7]>
The error handler cannot take care of such cases
<abu[7]>
It can only clean up FDs in 'in' or 'out' frames
<abu[7]>
So, in my view, these cases are not "leaks" in the sense that an application leaks memory, stack, file descriptors, temp files and what not
<abu[7]>
A leak would happen permanently
<abu[7]>
Here it happens only in an error condition which needs to be taken care of and fixed
<beneroth>
I agree
<abu[7]>
Technically fbytez is perfectly correct
<abu[7]>
But I see this pragmatically :)
<beneroth>
shot yourself in the foot, your own responsibility to go to the doctor.
<abu[7]>
☺
<beneroth>
picolisp doesn't shot in your foot, but it has not a lot of guardrails to prevent yourself from doing so.
<abu[7]>
yeah. Here nothing bad happens
<abu[7]>
Closing the FDs immediately would also contradict to pil normal error handling
<abu[7]>
The error prompt has still the environment (variables, call stack, open files etc.) at the time when the error occurred
<abu[7]>
Only when you press ^D, the stack is unwound, and besides other things also the FDs of I/O frames are closed
<abu[7]>
The fork however happens outside of such stack frames, the error handler cannot know about these FDs
<abu[7]>
It would also be very complicated (besides being too early) to clean up everything that was created before an error in forkLisp()
<abu[7]>
E.g. what if the third closeOnExec failed?