Re: Blocking read() from a USB->Serial adapter.
- From: Bjoern Schliessmann <usenet-mail-0306.20.chr0n0ss@xxxxxxxxxxxxxxx>
- Date: Sat, 25 Nov 2006 11:02:11 +0100
Charles Sullivan wrote:
I can understand the "attempts to read" for a non-blocking read -
returning fewer characters than specified if the characters
aren't immediately available to be read.
But I had the impression that a blocking read is supposed to block
forever or until it either reads the specified number of
characters or is interrupted.
"Blocking" or "nonblocking" matters only when no data at all is
available (e.g. if some disk has to position its head first, some
network connection is slow, or a pipe has no data).
Otherwise, both return all data the driver has available for you at
the moment (but only up to count bytes).
You're saying maybe it will and maybe it won't and that's to be
expected.
Yes. I was puzzled by that too when I first used unix read() and
write(), but you'll also have to accept it ;)
Not a problem. I am just puzzled why reading from the adapter
differs from reading from an actual serial port.
As already said here, it can be many reasons. Driver issues, timing
issues ...
Regards,
Björn
--
BOFH excuse #249:
Unfortunately we have run out of bits/bytes/whatever. Don't worry,
the next supply will be coming next week.
.
- References:
- Blocking read() from a USB->Serial adapter.
- From: Charles Sullivan
- Re: Blocking read() from a USB->Serial adapter.
- From: Bjoern Schliessmann
- Re: Blocking read() from a USB->Serial adapter.
- From: Charles Sullivan
- Blocking read() from a USB->Serial adapter.
- Prev by Date: KERNEL SIGNAL DELIVERY
- Next by Date: Re: KERNEL SIGNAL DELIVERY
- Previous by thread: Re: Blocking read() from a USB->Serial adapter.
- Next by thread: Re: Blocking read() from a USB->Serial adapter.
- Index(es):
Relevant Pages
|
