Re: nonblocking read

[Baurzhan Ismagulov]

On Tue, Nov 13, 2007 at 12:15:17AM +0100, Pawel Kot wrote:
> > > > > gnokii uses:
> > > > > if (select(...) > 0)
> > > > >   read(...);
> > > > > sequence to read from the file descriptor.  In case of bluetooth
> > > > > connection there may happen that gnokii/xgnokii/whatever is running
> > > > > and sending requests and then suddenly gets out of range. So what
> > > > > happenes there is that select() returns 1 and read() hands.
> > > >
> > > > IIUC, this should not happen.
...
> I disagree. Look at the following scenario:
> 1. Device is ready to write
> 2. Device writes
> 3. Program is doing select()
> 4. select() returns > 0
> 5. Device gets disconnected and the kernel discards all information
> regarding the device
> 6. Program is doing read()
> 7. read() fails

Failing immediately is ok. You said it was hanging for you, that was
what I didn't like.


> You may of course argue, that you should keep the information the
> device sent in some buffer. But how long? Who could discard it? What
> if device reconnects before someone reads the buffer?

It doesn't really matter as long as you don't block after telling
select(2) that you have something. You may fail and discard data, or you
may keep it in a buffer till the descriptor is closed, in which case
your driver's release function should take care of cleaning up.

The reconnection case depends on how you map real world to your Unix
device.


> You use select() to check if there is data to be read. Not that read()
> doesn't block.

My Linux select(2) man page says exactly that: read(2) won't block.


With kind regards,
-- 
Baurzhan Ismagulov
http://www.kz-easy.com/