[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: more on finalization issue, and reference implementation
From: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: more on finalization issue, and reference implementation
Date: Thu, 25 Aug 2005 18:58:58 +0200
> Shiro Kawai <shiro@xxxxxxxx> 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?