On Thu, Aug 18, 2011 at 5:27 PM, David Garfield < garfi...@irving.iisd.sra.com> wrote:
> I think you are right, that it is too easy, at least on its own. You > also should account for partial writes. > i currently account for partial writes but simply report them as errors (i have no recovery/retry strategy, which is what i'm aiming for here). With Pavel's information i think i now have what i need to (confidently) add this. i was missing the part about EINTR only happening if write() writes 0 bytes. i thought it could also happen on a partial write. So far i've been checking for partial writes but eliding signal checks for platform portability, but now it's reached a point where the code is stable but potential corruption cases which could be largely worked around via a retry-on-interrupt strategy. (i'm also investigating a journaling approach.) > I think the general rule is: if it wrote anything, it tells you how > much it wrote, which can be everything you asked it to write, or less. > If it wrote nothing, it usually returns -1 and sets errno based on why > it failed. You then can keep retrying if the error is EINTR or > EAGAIN, or maybe some others. > That's the key semantic i was missing. > I HOPE that an interrupt in a large interrupted write will NOT return > EINTR, because if it does, the partial write is screwed up. > i hope so, too! :-D Thank you for your insights! -- ----- stephan beal http://wanderinghorse.net/home/stephan/ _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
