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 07 Jun 2005 10:33 UTC
>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