>From: Michael Sperber <xxxxxx@informatik.uni-tuebingen.de>
Subject: Re: more on finalization issue, and reference implementation
Date: Thu, 25 Aug 2005 18:58:58 +0200

> Shiro Kawai <xxxxxx@lava.net> writes:
>
> > 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.
>
> You took my statement out of context: The "drop in" referred to a
> system where ports are already implemented.

I see.  I retract the word "replacement".

Still my concern isn't resolved.   An existing implementation has
this "flush-on-exit" behavior, MT safety, and async-finalization
support in its native port.  If I use the reference implementation
to build srfi-68 layer on top of it, I need to implement above
features _again_ in the srfi-68 port layer.  It can't be used
as is, and adapting it may not be trivial.

What I had in my mind is to make 'hooks' in the native port layer
so that the native port could call streams and/or reader/writer
layer if the user desired.  I can't be sure whether I can do it
efficiently enough until I actually write it up.  Although I don't
see any show-stoppers now, it would be nice if the srfi is
splitted up to the high-level port API and low-level stream/reader/writer
API, and the high-level port API is designed to work without
assuming low-level stuff.  Then I would implement the high-level
API first on top of native ports, and consider low-level stuff later.
But it's just my personal opinion.  I just wanted to raise a
concern that, in this srfi, any reference implementation can't
be a 'drop-in', unlike other srfis like srfi-1 etc.

> > (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.)
>
> Another approach is to iterate flushing until you get no more
> output, which is what Scheme 48 does.

Does the runtime system do it automatically upon program
termination?  In such a case, I guess you should have a weak
table to keep a set of opened ports, right?

--shiro