On Fri, Aug 19, 2011 at 4:10 PM, Pavel Ivanov wrote:
> No, it won't cause corruption. Because SQLite uses pwrite or its
> alternative with calls to lseek and write. So after interruption it
> will start writing at the same position it wrote previous time
> rewriting part of what it has already wr
On Fri, Aug 19, 2011 at 10:10 AM, Pavel Ivanov wrote:
> > If that is indeed the case, the current code will cause corruption on an
> > EINTR on such platforms because the EINTR handling does not account for a
> > non-0 write.
>
> No, it won't cause corruption. Because SQLite uses pwrite or its
>
> If that is indeed the case, the current code will cause corruption on an
> EINTR on such platforms because the EINTR handling does not account for a
> non-0 write.
No, it won't cause corruption. Because SQLite uses pwrite or its
alternative with calls to lseek and write. So after interruption it
On Thu, Aug 18, 2011 at 6:10 PM, Stephan Beal wrote:
> On Thu, Aug 18, 2011 at 5:27 PM, David Garfield <
> garfi...@irving.iisd.sra.com> wrote:
>
>> 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
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/re
On Thu, Aug 18, 2011 at 5:12 PM, Pavel Ivanov wrote:
> to proceed. BTW, if signal will interrupt write() after it has written
> part of the data already you won't get EINTR, you will get successful
> result just with amount written less than you asked for.
>
AHA! That's a little gem i didn't kno
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 se
> 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.
T
On Thu, Aug 18, 2011 at 4:39 PM, Pavel Ivanov 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
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.
Pavel
On Thu, Aug 18, 2011 at 9:38 AM, Stephan Beal wrote:
> Hi, sqlite3 hackers,
>
> i'm taking a look at os_unix.c:
>
> do{ got = osPwrite(id->h, pBuf
10 matches
Mail list logo
