Hi! On Tue, 2010-02-02 at 13:04:29 -0600, Jonathan Nieder wrote: > Package: zlib1g-dev > Version: 1:1.2.3.4.dfsg-3 > Severity: wishlist
> zlib’s gzFile interface provides no way I can see to recover from > EINTR. > Unfortunately, when zlib hits its first EINTR, two bad things happen: > > - the error indicator for the underlying stdio stream is set; > - the error number for the gzFile is set > and there is no way to undo either. So in fact this is an infinite > loop. > > Thoughts about fix: > I would love it if zlib just cleared the error indicator before each > potentially resumable operation (gzread(), gzwrite(), gzseek()). But > probably someone out there is relying on zlib _not_ to do that, as > part of his implementation of error recovery plan a above, so such a > change would be dangerous. > > Better would be to add a new gzclearerr() function to allow the two > error indicators to be explicitly cleared. There's already a gzclearerr provided by zlib, which clears both the EOF and error flags. And I think it's perfectly acceptable for code which might want to handle the interrupted case to call gzclearerr, and resume the previous zlib call. The actual problem though, as you initially pointed out in the debian-dpkg thread, is that not all zlib IO functions preserve enough state to always recover from a partial read/write. Because zlib uses now read(2)/write(2) functions for IO, on all write functions using gz_comp, the write might return a short count, but it does not store it anywhere or retries like its counterpart gz_load, which makes it impossible for the caller to restart the call even if having used gzclearerr. I had skimmed previously over the gzio.c (stdio based) code and there were several other problematic functions, but doing so now over the new gzlib.c based code it seems to be in a way better shape, although there might still be some other problems, I've not checked thoroughly. The EINTR, EAGAIN, EWOULDBLOCK errors seem to be safe to be handled now with gzclearerr, as there's no possibility of a partial fread/fwrite returning with those anymore. regards, guillem -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
