Email list hosting service & mailing list manager

closing reader / writer Shiro Kawai (25 May 2005 00:28 UTC)
Re: closing reader / writer Michael Sperber (06 Jun 2005 15:12 UTC)
Re: closing reader / writer Shiro Kawai (07 Jun 2005 10:33 UTC)
Re: closing reader / writer Michael Sperber (08 Jun 2005 07:24 UTC)
Re: closing reader / writer Shiro Kawai (08 Jun 2005 07:55 UTC)
Re: closing reader / writer Michael Sperber (09 Jun 2005 05:53 UTC)

Re: closing reader / writer Shiro Kawai 08 Jun 2005 07:55 UTC

>From: Michael Sperber <xxxxxx@informatik.uni-tuebingen.de>
Subject: Re: closing reader / writer
Date: Wed, 08 Jun 2005 09:24:58 +0200

> Shiro Kawai <xxxxxx@lava.net> writes:
>
> > 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.
>
> I don't understand how the asynchronous nature of finalizers comes in:
> By nature, in this scenario, the finalizer can only be called *after*
> the Scheme program is finished with a reader or writer, so no
> interleaving with explicit calls from the user program is possible.

Suppose I'm managing a pool of resources for a special kind of
reader (or writer).  Every time such a reader is requested, my
constructor allocates the resource from the pool, calls
make-simple-reader, and return the created reader.  Every time
the reader is closed, my 'close' procedure returns the resource
to the pool.

If the 'close' procedure can be called from finalizers, it is possible
that the 'close' procedure is called while the constructor is running
to create another reader.  So a race condition on the access to
the resouce pool can happen.

--shiro