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? --shiro