[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] valid implementation of call-with-input-file?
On Sun, Aug 19, 2012 at 6:38 PM, Peter Bex <Peter.Bex@x> wrote:
> On Sun, Aug 19, 2012 at 11:23:03AM +0200, Andy Wingo wrote:
>> Hello,
>>
>> Is this implementation of call-with-input-file valid?
>>
>> (define (call-with-input-file filename proc)
>> (let ((port (open-input-file filename)))
>> (with-exception-handler
>> (lambda (x)
>> (close-input-port port)
>> x)
>> (lambda ()
>> (call-with-values (lambda () (proc port))
>> (lambda vals
>> (close-input-port port)
>> (apply values vals)))))))
>>
>> I think no, due to the language on p52 of the report:
>>
>> If proc does not return, then the
>> port must not be closed automatically unless it is possible
>> to prove that the port will never again be used for a read
>> or write operation.
>>
>> I think we should specify that exceptional exits close the port, as the
>> above implementation does.
>
> I've argued this point on several occasions before, but nobody listened :(
I'm sorry you got that impression. I've argued the same thing.
You may not have gotten much feedback because we had
discussed this already on the WG1 list.
> With the current behavior users will need to remember to wrap each and
> every call to call-with-input-file or with-input-from-file that *might*
> cause an error (ie, probably ALL of them) in an exception handler.
> This is very un-Schemely since it means the default behavior is simply
> unusable.
The problem is that you could have continuable
exception, in which case it would be premature to close
the port. Even with non-continuable exceptions, you
could be dropped into a debugger where you might want
to examine the port.
There was discussion about having some sort of
alternative to unwind-protect - it would _not_ be
triggered simply by dynamic-wind (which is normal
with continuations), but rather would only trigger
on exceptions (I had tentatively proposed the name
exception-protect). It would be presumptuous to
have the call-with-* procedures use this automatically,
for the above reasons, but users could call this
themselves, and optionally we could have a
safe-call-with-* procedure.
The problem is this is straying into invention, so
the general sentiment was to leave it to WG2.
It's expected that implementations close files on
gc, and a good implementation should gc when out
of file descriptors as well. An alternate approach
to more timely releasing of resources would be
to add stronger guarantees about when gc occurs -
again, an area of open research not yet ready for
WG1.
--
Alex
_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports