Re: nonblocking read

[Pawel Kot]

Hi,

On Nov 11, 2007 12:57 PM, Baurzhan Ismagulov <address@hidden> wrote:
> Hello Paweł,
>
> On Sat, Nov 10, 2007 at 09:55:27PM +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. The select(2) man page on my Linux system
> says: "select()... allows a program to monitor multiple file
> descriptors, waiting until... it is possible to perform... I/O operation
> (e.g., read(2)) without blocking".

These are not atomic operations. At the time of select() defice may be
indeed ready, but at read() not anymore.

> If you have double-checked that readfds is FD_ISSET for the file
> descriptor you are trying to read, the best thing to do would probably
> be to talk with the driver maintainers.

Why? It makes perfect sense why it doesn't work.

> > Is there a way to make it timeout after some time not breaking other
> > stuff?
>
> If you are determined to behave correctly also with buggy drivers, the
> next best thing to do would be using O_NONBLOCK. Otherwise, you can
> always use alarm(2), but this is, in my experience, difficult to
> maintain in the long term (unless, perhaps, you implement a timer API
> that plays well with your main loop, etc., which, IMHO, isn't worth it
> if you can live with one of the two options above).

That's what the patch below does.

> > I tried http://tfuj.pl/gnokii/nonblockingsocket.patch but it makes
> > open() not working well (open() in our case should be blocking).
>
> This is interesting. What does "not working well" mean? I've used
> non-blocking I/O for serial devices and TCP sockets without problems.

I got "Operation now in progress" from connect() in bluetooth case.

take care,
pkot
-- 
Pawel Kot