[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: more on finalization issue, and reference implementation

This page is part of the web mail archives of SRFI 68 from before July 7th, 2015. The new archives for SRFI 68 contain all messages, not just those from before July 7th, 2015.

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?