How about real garbage collection?
ceving
garbage collector. This explains the following error:
(let loop ((n 2000))
(if (> n 0)
(begin
(open-input-file "/etc/motd")
(loop (- n 1)))))
ERROR in open-input-file: couldn't open input file: "/etc/motd"
On my test system the file descriptor limit is 1024:
$ ls /proc/$(pgrep chibi-scheme)/fd|wc -l
1024
It seems to be normal for the Scheme community that people have memory
collection in mind when they say garbage collection. The list of
Scheme implementations which do not have a real garbage collector is
long: Gambit, Chicken, Bigloo, Guile, Scsh. The list might be even
longer but I stopped testing after Scsh. I think Common Lisp would not
fail, because it has finalization support.
This leads to the question: will Chibi support finalization some day?
This is in particular useful when doing networking. I ran in some
CLOSE_WAIT errors with Chicken this week, because I accidentally
thought that a garbage collector will collect also file descriptors.
After some discussion on the Chicken mailing list I found out that no
Scheme I am aware of does it right.
Alex Shinn
> Right now (0.5.2) Chibi has only a memory collector instead of a
> garbage collector. This explains the following error:
>
> (let loop ((n 2000))
> (if (> n 0)
> (begin
> (open-input-file "/etc/motd")
> (loop (- n 1)))))
>
> ERROR in open-input-file: couldn't open input file: "/etc/motd"
Chibi does reclaim file descriptors on gc, the problem
is just that it only calls gc automatically when out of
memory. If you insert a call to (gc) in the loop it works.
I've just checked in a change so that Chibi will gc when
out of file descriptors, so the above works unmodified.
--
Alex
Benjohn Barnes
On 16 Dec 2011, at 15:08, Alex Shinn wrote:
> I've just checked in a change so that Chibi will gc when
> out of file descriptors, so the above works unmodified.
I like garbage collection a lot, but I'm uncomfortable with relying on it to also clean up resources like this in the style of c++ raii.
There seem to be many resources where when the GC decides to clean them up is hardly an optimal moment to release them. Perhaps part of the problem is that heterogeneous resource types are thrown in to a single homogenous garbage collected pool with one collection policy (the heap)?
Are there some standard approaches to this kind of management?
It feels like something where you want an abstraction who's semantics make closing resources much more explicit, but you'd want the abstraction not to get in the way, or prevent you using the resource as you wish. Eg – it's easy to write a function that opens a file and runs a function on it, then closes the file. That might be fairly useless when multiple files need to be opened and stay open for an indefinite period, being closed in a different order. I don't suppose it would play nicely with a continuation using the file being returned from the abstraction either.
Thanks,
Benjohn
--
ben...@fysh.org - Twitter @benjohnbarnes - Skype (sometimes) benjohnbarnes - Mobile +44 (0) 7968 851 636
Alex Shinn
>
> On 16 Dec 2011, at 15:08, Alex Shinn wrote:
>
>> I've just checked in a change so that Chibi will gc when
>> out of file descriptors, so the above works unmodified.
>
> I like garbage collection a lot, but I'm uncomfortable with relying on it to also clean up resources like this in the style of c++ raii.
>
> There seem to be many resources where when the GC decides to clean them up is hardly an optimal moment to release them. Perhaps part of the problem is that heterogeneous resource types are thrown in to a single homogenous garbage collected pool with one collection policy (the heap)?
>
> Are there some standard approaches to this kind of management?
Yes, in general Scheme programmers don't rely on GC
for these cases, but instead use interfaces such as
with-input-from-file
call-with-input-file
call-with-port
which automatically close the file on return.
However, programmers write buggy code, and if you
want a long-running environment it's helpful to be
able to automatically clean up after the programmer's
mistakes.
--
Alex
ceving
>
> > I've just checked in a change so that Chibi will gc when
> > out of file descriptors, so the above works unmodified.
>
> I like garbage collection a lot, but I'm uncomfortable with relying on it to also clean up resources like this in the style of c++ raii.
>
> There seem to be many resources where when the GC decides to clean them up is hardly an optimal moment to release them.
I can not understand the problem you see. A garbage collector
finalizes something after all references are gone to the resource. If
your resource has some specific needs concerning the finalization you
have to keep a reference in order to be able to fulfill this needs. In
this case the garbage collector would not do anything. I think it is
obvious that a garbage collector will only emerge if the programmer
does not care about the finalization or when he is not able to do the
finalization. This is the case in a language with continuations. Not
having a garbage collector requires excessive exception handling to
take care that no resources are leaking. And additionally you have to
intercept all kinds of continuation exits. How do you want to do this?
In a language without continuations this might be possible but in
Scheme this is not practical.
Benjohn Barnes
On 18 Dec 2011, at 20:21, ceving wrote:
> On 18 Dez., 14:01, Benjohn Barnes <benj...@fysh.org> wrote:
>>
>>> I've just checked in a change so that Chibi will gc when
>>> out of file descriptors, so the above works unmodified.
>>
>> I like garbage collection a lot, but I'm uncomfortable with relying on it to also clean up resources like this in the style of c++ raii.
>>
>> There seem to be many resources where when the GC decides to clean them up is hardly an optimal moment to release them.
>
> I can not understand the problem you see.
I'm musing, really :-) I'm thinking about such things as textures and other resource in an openGL program, or a representation of a computer games level. Things where you definitely do need to explicitly control lifetime. So it's probably irrelevant.
Alex Shinn
>
> On 18 Dec 2011, at 20:21, ceving wrote:
>
>> On 18 Dez., 14:01, Benjohn Barnes <benj...@fysh.org> wrote:
>>>
>>>> I've just checked in a change so that Chibi will gc when
>>>> out of file descriptors, so the above works unmodified.
>>>
>>> I like garbage collection a lot, but I'm uncomfortable with relying on it to also clean up resources like this in the style of c++ raii.
>>>
>>> There seem to be many resources where when the GC decides to clean them up is hardly an optimal moment to release them.
>>
>> I can not understand the problem you see.
>
> I'm musing, really :-) I'm thinking about such things as textures and other resource in an openGL program, or a representation of a computer games level. Things where you definitely do need to explicitly control lifetime. So it's probably irrelevant.
Actually, prompt cleanup of file descriptors is important.
The OS is unable to release any space used by a file
even after it's been removed so long as there are open
fd's on it. So if you forget to close an fd for a multi-gigabyte
log file, there's no way to reclaim the space without
killing the offending process.
--
Alex