more on finalization issue, and reference implementation Shiro Kawai (25 Aug 2005 02:39 UTC)
|
||
Re: more on finalization issue, and reference implementation
Michael Sperber
(25 Aug 2005 16:59 UTC)
|
||
(missing)
|
||
(missing)
|
||
Re: more on finalization issue, and reference implementation
Shiro Kawai
(28 Aug 2005 23:01 UTC)
|
||
Re: more on finalization issue, and reference implementation
Per Bothner
(25 Aug 2005 17:36 UTC)
|
||
Re: more on finalization issue, and reference implementation
Michael Sperber
(13 Sep 2005 12:25 UTC)
|
more on finalization issue, and reference implementation Shiro Kawai 25 Aug 2005 02:40 UTC
I think POSIX stdio guarantees the program termination (either by returning from main() or calling exit(2)) causes stdout flushed, so the following program always print "Hello" (without newline) to the stdout. #include <stdio.h> int main(int argc, char **argv) { printf("Hello"); return 0; } Although R5RS doesn't say anything about it, it is natural for programmers with POSIX background to expect the same behavior in the following program (assuming srfi-22): (define (main args) (display "Hello") 0) This behavior is automatically achieved if the implementation is using system's buffered I/O directly to implement ports. The srfi-68 author has suggested the reference implementation to be a drop-in replacement for existing implementations, but it is not obvious how such implementations guarantee the "flush-on-exit" behavior. It is a practical issue. When I switched Gauche's I/O system from stdio to own buffering, I overlooked this problem and got reports that existing programs had broken, and I had to implement a weak pointer table to manage opened ports. (Object finalization on the program termination may or may not save this. If finalizers run with considering dependencies, the port can be finalized before underlying streams and writes, so it's OK. However, it is generally difficult to run finalizers strictly observing dependencies (e.g. there can be a circular reference) and the implementation may choose to run finalizers without ordering.) It's fine that srfi-68 leaves this issue open to the implementations. However, claiming the reference implementation as a practical replacement to the existing implementation's I/O layer could be an overstatement. Considering issues like this or port-locking (*1) or asynchronous finalization (*2), I imagine it is extremely difficult to provide even reasonably working code as a single universal reference implementation. I do see the usability of customizable ports, but srfi-68 seems too large for me to have confidence that it surely work under different implementations. Maybe it's a good idea to split it to smaller modules, each of which can be easily implemented by different implementations and can be confirmed it works. (*1) http://srfi.schemers.org/srfi-68/mail-archive/msg00042.html (*2) http://srfi.schemers.org/srfi-68/mail-archive/msg00021.html --shiro