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: 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