>From: Michael Sperber <xxxxxx@informatik.uni-tuebingen.de>
Subject: Re: closing reader / writer
Date: Mon, 06 Jun 2005 17:12:35 +0200

> > It may also be good to note that the 'close' procedure passed to
> > make-simple-reader/make-simple-writer is called only synchronously,
> > when reader-close/write-close procedure is called.
>
> I'm not sure what this would mean.  With "synchronously," do you mean
> to prevent other processes in the system, such as GC or finalization?
> You seem to be saying that below ...

Yes, I meant the finalization issue.

What I can do in the 'close' procedure is affected so much by
whether 'close' procedure may be called from finalizers or not.
Because of the asynchronous nature of the finalizers,
when the finalizer is involved, I need to write 'close' procedure
with care as if I'm writing preemptive multithreaded program,
even if the program itself is single threaded.

Finalizers are handy and sometimes inevitable, so I don't think
it should be absolutely avoided.  But if you mean to allow 'close'
procedures to be called from finalizers, I think it should be
noted in the srfi spec.  Otherwise, a library that naively assumed
only synchronous call of 'close' procedure may fail randomly on
the implementation that may call it asynchronously.

The situation is similar to MT-safeness.   The library can be
MT-unsafe, and it is OK, as far as the authors and the users
know it.

Most Scheme implementations release the system resources when
a port is GC-ed, but it doesn't raise this issue since they are
handled atomically "under the hood".   The Scheme program can
rely on the implementation that serializes operations to its
internal resource pools.   Once you open up this low-level stuff
to Scheme world, the problem becomes visible.

If you do allow asynchronous call, maybe it is nice to provide
a way for the 'close' procedure to know whether it is called
synchronously or asynchoronously.

--shiro