I think you are right, that it is too easy, at least on its own. You also should account for partial writes.
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. I HOPE that an interrupt in a large interrupted write will NOT return EINTR, because if it does, the partial write is screwed up. Stephan Beal writes: > On Thu, Aug 18, 2011 at 4:39 PM, Pavel Ivanov <paiva...@gmail.com> wrote: > > > If you don't want your library behavior to be changed when process > > receives some signals then you have to use such or some similar > > approach. > > > > i understand the reason for it, but before i go adding this to my storage > API i just wanted to ask for some opinions as to whether this approach is > generically both technically and philosophically sound, or whether the fact > that it works at all relies on other voodoo deep within os_unix. > > The main thing that troubles me is that this approach just seems "too easy" > given this particular problem, and i'm suspicious because of that. It > _seems_ to be exactly what i'm looking for, but i also know that my > knowledge for the effect of EINTR on system calls is too constrained for me > to have my own educated, confident opinion on it. > > -- > ----- 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 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
