[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] [BUG] serious bug in vu_write_retry?
From: |
Tom Lord |
Subject: |
Re: [Gnu-arch-users] [BUG] serious bug in vu_write_retry? |
Date: |
Fri, 9 Jul 2004 10:44:16 -0700 (PDT) |
> From: Aaron Bentley <address@hidden>
> Tom Lord wrote:
> > > From: Aaron Bentley <address@hidden>
> > > I'm not so sure about the interface itself. Shouldn't it return
> > > a short count if it partially succeeds?
> > There is no portably correct
> > and interestingly useful short count to return for other errors.
> So, when vu_write returns -1, it may have written something?
Not if errno is EINTR or EAGAIN.
Otherwise, it depends on the specific error and the specific
descriptor. Consult your system's documentation.
>> Allowing the _retry functions to return a partial count would
>> make them the same, for nearly all practical purposes as plain
>> old read/write: there'd be no point to having the _retry
>> functions at all.)
> There'd be the distinction that when vu_write doesn't complete,
> you may want to retry, but when vu_write_retry doesn't complete,
> it's pointless.
Fair enough. _If_ there was a short-count that could be meaninfully
returned, then it might make sense to return that from _retry
functions and have callers test for (count == vu_...) rather than (0
= vu_...).
> It's just a return value thing, and doesn't change what the functions
> do. You'll get get same behaviour from both if you do:
> if (vu_write_retry(count) != count)
> panic("write could not be completed")
> But whatever. I doubt it makes much difference, as you say, given the
> intended use of the function.
There's no meaningful short-count to return. That's the fatal thing
for the idea.
-t