gnu-arch-users
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]