On 3/4/07, Jim Jewett <[EMAIL PROTECTED]> wrote: > On 3/4/07, Adam Olsen <[EMAIL PROTECTED]> wrote: > > On 3/4/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote: > > > > .nonblockflush() would be fine with me, but I don't think .flush() > > > should block on a non-blocking object. ... > > I don't think flush should even be called on an object that is > (intentionally) non-blocking. The fact that it was called suggests > that the application doesn't realize/care about the non-blocking mode. > (Or at least doesn't like it at this particular moment.) > > > > How about .flush() write as much as it can, and throw an exception if > > > not all of the bytes can be written to the device? (again, this would > > > only come up when a user has set the underlying file descriptor to > > > non-blocking mode) > > > I see little point in having an interface that randomly fails > > depending on the stars, phase of the moon, etc. If the application is > > using the interface wrong then we should fail every time. > > (Based on the fflush information at > http://opengroup.org/onlinepubs/007908799/xsh/fflush.html) > > Random failures are unavoidable; the application can't know how full > the disk already was. (ENOSPC)
I wouldn't call a full disk a random failure, at least not in the same sense. What I meant was during development, with no disk load by other processes, the program would work fine. When deployed a user may have other apps running and once a week there's just enough disk load that the flush can't complete immediately. Then the process exits, it's still non-blocking so it won't stop, so the file never gets flushed properly. > > The reason not to raise a would-block exception (EAGAIN) is that the > application *can* recover by just waiting a while. The boilerplate to > do that wait-and-recover should be handled once by python, instead of > repeated in every paranoid application that worries it *might* be > handed a device that *happens* to be non-blocking. Making .flush() internally use select() so that it still behaves in a blocking fashion to the application is perfectly acceptable to me. The alternative, in my mind at least, is that a TypeError of ValueError be raised because this interface is not designed to be used in non-blocking mode and it's bug in the applicatino to attempt it. The app should be using the right interface instead, .nonblockflush() or the like. One interface, one behaviour, no guessing. -- Adam Olsen, aka Rhamphoryncus _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
