> Great addition, although I'm a bit uncertain about whether it would > be more suitable to instead add it to Stdio.FILE.
Well, that is not usually what you get from accept() and such. Also, it's not all that usable in Stdio.FILE, since that one can be widestring based. > One thing that I'm missing is a way to enqueue a close on write > done. > Hmm... Maybe the something like the following would work? > fd->set_write_callback(Function.uncurry(Function.uncurry( > Function.curry(fd->close, "w")))); In your write callback, add fd->close()? It will only be called when the buffer is empty. That is basically when the ->set_write_callback above does, but it's probably easier to simply set a normal write callback. :) > >Currently read() and write() are not in any way modified by having > >buffered output enabled, if you interact directly with the file object > >it will bypass the buffer. I am unsure if this is a good idea or not. > It doesn't sound like a good idea, since it would cause interleaving > between the manual and automatic calls at random places in the stream, > and it would be complicated to recover in a deterministic way. I sort of agree. It's easy enough to make them redirect data to and from the buffers instead. It was just that that would be an actually noticeable change to the file object. Not a huge one, really, but somewhat sizable. Having close buffered is however probably not needed for most buffered protocols. If you do want a delayed close, simply set the write callback to one that calls fd->close. -- Per Hedbor
