more on finalization issue, and reference implementation

[Shiro Kawai <shiro@xxxxxxxx>]

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