On Tue, Mar 18, 2003 at 09:28:36AM -0500, Dan Sugalski wrote: > At 3:00 PM +0100 3/18/03, Juergen Boemmels wrote: > >Benjamin Goldberg <[EMAIL PROTECTED]> writes:
> >> So... it is a slow system call, with no visible > >> effect -- why do we do it? > > > >Deepends on the semantics we want to have for flush. I thought of > >flush to disk, but just flush to OS is also a valid asumption. This is > >what fflush also does. > > Given that we're not going to be using the C std library except in > the most extraordinary of circumstances, I don't know that there's > much point in a flush that doesn't actually force the write to the > disk. perl5.8 turned PerlIO from a stdio veneer into a full IO system, designed to provide perl with Unicode capable IO, and also look enough like stdio to keep embedded programs happy at source level. The "layers" it use eventually pump data to the OS via calls such as write() on Unix, and layers have a C struct that acts as a vtable full of methods. One problem that I felt was present during development, which persists into release, is that there is only one sync/flush method. The buffered layers write methods are tending to be implemented as write into the layer's buffer, and then call that layer's flush method to empty it. This allows new layers to be derived, with the write being over-ridden in the child, but flush being unchanged as the parent's implementation. The problem the upper levels were using flush as described - a call to make on themselves when they wanted their buffer emptied by the layer below. The layers at the base of the heap (such as "Unix") were treating flush as fsync() - get the data out as far as possible. I'm biased - I know that Nick Ing-Simmons (the implementor) spotted a problem with this recently, but I can't remember what it is. However, I know what my problem was with all this - I was writing a gzip compression layer. There's a big distinction between "bulk pump more data" and "this data is hot, get it out fast". The former is normal operation, the latter means call zlib with the flag to flush all data straight through, even if the compression ratio drops. (It's what you need to compress interactive streams) In PerlIO as currently implemented, the upper layer calls my flush method (from its flush method) every time it empties its buffer. But it also might call flush when it really wants interactive data passed on in a timely fashion. So should I drop the compression off every time I get flushed? Or was it crying wolf? Oops. This turned into a ramble. "flush" ne "sync". If both are needed in different places, provide both as distinct methods. Nicholas Clark
