Robert Hancock wrote:
It's because you haven't done anything to handle the error which is
still persisting. Likely the only thing sane you can do in this case is
close the fd and try to reopen it later.
This seems to be true, but not for what you might think.
It appears that if u plug the U
> David Schwartz wrote:
> >> The misunderstanding is from the docs.
> >> The select() does not report device errors.
> >> Select will just "more precisely, to see if a read will not block".
> > This is a much slighter misunderstanding. The result of the 'select'
> > function tells you nothing ab
David Schwartz wrote:
The misunderstanding is from the docs.
The select() does not report device errors.
Select will just "more precisely, to see if a read will not block".
This is a much slighter misunderstanding. The result of the 'select'
function tells you nothing about what a particular 'r
> The misunderstanding is from the docs.
> The select() does not report device errors.
> Select will just "more precisely, to see if a read will not block".
This is a much slighter misunderstanding. The result of the 'select'
function tells you nothing about what a particular 'read' will or will
David Schwartz wrote:
David Schwartz wrote:
Nope. An errored connection is always ready for read/write -- there is
nothing to wait for as far as the kernel is concerned. Your code keeps
asking the kernel if something interesting has happened, the
kernel keeps
telling it yes, and it refuses to
> David Schwartz wrote:
> > Nope. An errored connection is always ready for read/write -- there is
> > nothing to wait for as far as the kernel is concerned. Your code keeps
> > asking the kernel if something interesting has happened, the
> > kernel keeps
> > telling it yes, and it refuses to do
Uncle George <[EMAIL PROTECTED]> wrote:
> i am using the GARMIN_GPS/usb driver to read a gps receiver.
> In testing the ability of my software to recover from various errors, I
> try this: unplug the gps/USB cable from the usb hub.
>
> Interestingly enough the thread spins.
> the SELECT() waits f
David Schwartz wrote:
In this case what, will reset the "something interesting has happened"
report from the SELECT call? Will it ever be reset in this case?
Nope. An errored connection is always ready for read/write -- there is
nothing to wait for as far as the kernel is concerned. Your code
Uncle George wrote:
David Schwartz wrote:
Nope. An errored connection is always ready for read/write -- there is
nothing to wait for as far as the kernel is concerned. Your code keeps
asking the kernel if something interesting has happened, the kernel keeps
telling it yes, and it refuses to do
David Schwartz wrote:
Nope. An errored connection is always ready for read/write -- there is
nothing to wait for as far as the kernel is concerned. Your code keeps
asking the kernel if something interesting has happened, the kernel keeps
telling it yes, and it refuses to do anything about it.
T
> i am using the GARMIN_GPS/usb driver to read a gps receiver.
> In testing the ability of my software to recover from various errors, I
> try this: unplug the gps/USB cable from the usb hub.
>
> Interestingly enough the thread spins.
> the SELECT() waits for something to happen, and I get one cha
11 matches
Mail list logo
