[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: nonblocking read

From: Baurzhan Ismagulov
Subject: Re: nonblocking read
Date: Sun, 11 Nov 2007 12:57:51 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

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".

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.

> 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).

> I tried 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.

With kind regards,
Baurzhan Ismagulov

reply via email to

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