Harry wrote:
Hi all,

I establish a bluetooth connection and created a virtual serial port
called /dev/rfcomm0. I open this device and wait for data in
select() . I receive data from another PC and process it properly. But
when i disconnect, select() returns SUCCESS which seems to be strange.

select() doesn't return SUCCESS.

from man select:

"On success, select() and pselect() return the number of file descriptors
contained in the three returned descriptor sets (that is, the total
number of bits that are set in readfds, writefds, exceptfds) which may be
zero if the timeout expires before anything interesting happens. On error,
-1 is returned, and errno is set appropriately; the sets and timeout become
undefined, so do not rely on their contents after an error."

--
SF

Games are very educational. Scrabble teaches us vocabulary, Monopoly teaches
us cash-flow management, and Dungeons & Dragons teaches us to loot dead bodies.

I guess what happens here is the common confusion about what
select() tells you. It doesn't tell you that there's something
you can read but that there's a file descriptor you can call
read() on without getting blocked.

Hi all,

I establish a bluetooth connection and created a virtual serial port
called /dev/rfcomm0. I open this device and wait for data in
select() . I receive data from another PC and process it properly. But
when i disconnect, select() returns SUCCESS which seems to be strange.

I establish a bluetooth connection and created a virtual serial port
called /dev/rfcomm0. I open this device and wait for data in
select() . I receive data from another PC and process it properly. But
when i disconnect, select() returns SUCCESS which seems to be strange.

I am sorry for that "SUCCESS". You are right, but i don't get either
-1 or 0.

By SUCCESS i meant the same thing.

On Aug 28, 5:14 pm, Dildo Bogumil di Boscopelo <psycho... at (no spam) libero.it
wrote:
Harry wrote:
Hi all,

I establish a bluetooth connection and created a virtual serial port
called /dev/rfcomm0. I open this device and wait for data in
select() . I receive data from another PC and process it properly. But
when i disconnect, select() returns SUCCESS which seems to be strange.

select() doesn't return SUCCESS.

from man select:

"On success, select() and pselect() return the number of file
descriptors
contained in the three returned descriptor sets (that is, the total
number of bits that are set in readfds, writefds, exceptfds) which
may be
zero if the timeout expires before anything interesting happens. On
error, -1 is returned, and errno is set appropriately; the sets and
timeout become
undefined, so do not rely on their contents after an error."

--
SF

Games are very educational. Scrabble teaches us vocabulary, Monopoly
teaches us cash-flow management, and Dungeons & Dragons teaches us to
loot dead bodies.

On Aug 28, 7:00 am, j... at (no spam) toerring.de (Jens Thoms Toerring) wrote:

I guess what happens here is the common confusion about what
select() tells you. It doesn't tell you that there's something
you can read but that there's a file descriptor you can call
read() on without getting blocked.

That's a very inaccurate statement of what 'select' is telling you.
It's like saying that 'statfs' tells you how much disk space you can
use without getting a 'disk full' error. The return from 'select' is
not remembered somehow to turn the next 'read' call into a non-
blocking one.

Ok, I try to be more precise: If select() returns 1 and one
of the entries in the returned fd_set for reading is set,
then one is guaranteed that a read() call for the corres-
ponding file won't block.

But that doesn't guarantee that
read() will return a single byte from the file descriptor,
it may also return 0, either because whatever was writing
to that file descriptor has closed, because the end of the
file had already been reached or because it's a descriptor
for something that was opened in non-blocking mode (but then
calling select() for that file descriptor hardy makes sense).

What I think is important to understand is that select() tells
you "for one of the files descriptors I am waiting for in the
set of read/write descriptors the next I/O operation will not
block" and not "there are data to be read or data can be writ-
ten for one of these file descriptors".

On Aug 28, 7:00 am, j... at (no spam) toerring.de (Jens Thoms Toerring) wrote:
I guess what happens here is the common confusion about what
select() tells you. It doesn't tell you that there's something
you can read but that there's a file descriptor you can call
read() on without getting blocked.

That's a very inaccurate statement of what 'select' is telling you.

It's like saying that 'statfs' tells you how much disk space you can
use without getting a 'disk full' error.

The return from 'select' is not remembered somehow to turn the next
'read' call into a nonblocking one.

It is almost literally identical to the definition of select:

        A descriptor shall be considered ready for reading when a call
        to an input function with O_NONBLOCK clear would not block[1]

Which means the same as 'read can be called without blocking[2]' (it
still doesn't mean 'had read been called, the call would not have
blocked'[3*])

It's like saying that 'statfs' tells you how much disk space you can
use without getting a 'disk full' error.

This is still a wrong analogy: 'statfs' returns the amount of free
disk space at the time of the call.

Under normal conditions, the
amount can change at any time because the disk (being mounted
somewhere in the filesystem tree) is a resource shared by all running
processes, each of which may consume (or free) diskspace whenever it
actually runs. If the resource whose status select has reported is
shared depends both on the resource and on the execution history of
the system, ie which other processes can acess it, for instance,
because they have an open file descriptor refering to it, too. It need
not be shared, although it may.

The return from 'select' is not remembered somehow to turn the next
'read' call into a nonblocking one.

The condition which caused select to indicate that a particular
descriptor would be readable is 'remembered somehow' (otherwise,
select couldn't have checked it)

and without 'something' happening
which changes this state, it won't change.

  A descriptor shall be considered ready for reading when a call to an
  input function with O_NONBLOCK clear would not block, whether or not
  the function would transfer data successfully. (The function might
  return data, an end-of-file indication, or an error other than one
  indicating that it is blocked, and in each of these cases the des-
  criptor shall be considered ready for reading.)

  A descriptor shall be considered ready for writing when a call to
  an output function with O_NONBLOCK clear would not block, whether
  or not the function would transfer data successfully.

As far as I understand this it looks to me more or less like what
I wrote, i.e. that if select() indicates that a file descriptor is
readable a read() call won't block (but nothing else).

So my inter-
pretation is that select() actually makes a promise about what will
happen in the future.

The man page on my system is even more straight to the point:

   A file descriptor  is considered ready if it is possible to
   perform the corresponding I/O operation (e.g., read(2))
   without blocking.

While I can easily follow your argument about access() and what
guarantees it's not making, I am not yet convinced that this is
also valid for select(). With access() you make a query for an
a file that your process hasn't any direct connection with (you
just pass it the name of a file you didn't open (yet0 and which
could go away or be changed at any moment). But with  select()
you make a query for an "object" (file, pipe, socket etc.) you
already did open, so you should get some more reliable informa-
tion about what you can or can't do with it.

Certainly making
predictions about the future is extremely difficult but according
to my reading of POSIX I would assume that this is what's expected
from select() (and having been at the "promising end" when writing
a device driver that supported a select() call I understand that
it's something not always trivial to get right).

Thank you for the interesting discussion, I am looking forward to
your reply (but it's now time to go to bed over herer, so don't
expect replies from me tonight anymore;-). Perhaps we should take
this to comp.unix.programmer since to me it does not seem to be
just Linux specific but a question concerning all versions of
UNIX versions that try to be POSIX compliant.

On Aug 28, 10:06 am, j... at (no spam) toerring.de (Jens Thoms Toerring) wrote:

Ok, I try to be more precise: If select() returns 1 and one
of the entries in the returned fd_set for reading is set,
then one is guaranteed that a read() call for the corres-
ponding file won't block.

Nope, that's not true. No system call makes that kind of future
guarantee.

But that doesn't guarantee that
read() will return a single byte from the file descriptor,
it may also return 0, either because whatever was writing
to that file descriptor has closed, because the end of the
file had already been reached or because it's a descriptor
for something that was opened in non-blocking mode (but then
calling select() for that file descriptor hardy makes sense).

Or, it might block.

What I think is important to understand is that select() tells
you "for one of the files descriptors I am waiting for in the
set of read/write descriptors the next I/O operation will not
block" and not "there are data to be read or data can be writ-
ten for one of these file descriptors".

No, it doesn't predict the future. This is a common misunderstanding,
and it's a very serious one. Just as 'access' doesn't guarantee you
that a subsequent access will actually succeed, so 'select' doesn't
tell you that a subsequent access won't block.

What both of these functions tell you is that a particular status
existed during at least some instant in-between when you called the
status-reporting function and when that function returned. None of the
functions guarantee that this status will still be the case later when
you decide to act on it.

On Aug 28, 4:53 pm, j... at (no spam) toerring.de (Jens Thoms Toerring) wrote:

  A descriptor shall be considered ready for reading when a call to an
  input function with O_NONBLOCK clear would not block, whether or not
  the function would transfer data successfully. (The function might
  return data, an end-of-file indication, or an error other than one
  indicating that it is blocked, and in each of these cases the des-
  criptor shall be considered ready for reading.)

  A descriptor shall be considered ready for writing when a call to
  an output function with O_NONBLOCK clear would not block, whether
  or not the function would transfer data successfully.

Notice again the "would", not "will".

As far as I understand this it looks to me more or less like what
I wrote, i.e. that if select() indicates that a file descriptor is
readable a read() call won't block (but nothing else).

A read call *WOULD* not block, had there been one at the time.

This is the same for 'access'. Access indicates that an open would not
fail (if issued at the time).

So my inter-
pretation is that select() actually makes a promise about what will
happen in the future.

Nope. Where does it say that?

No status-reporting function makes a promise about what will happen in
the future. And make no mistake about it, select is a status-reporting
function. "Ready to read" is a status.

Basically, that means that the use of select() I have seen at
more than once, i.e. calls of  select() when waiting for some-
thing to read with a timeout in order not to wait longer than
a certain amount of time, can backfire badly if one of the file
descriptors becomes ready for reading, the process than calls
read() but in the mean time the status has changed again and
the process now waits for an arbitrary long time, being blocked
until it can really read.

So one would either need some kind of "atomic" select and do I/O
function to get it right or, without that existing, one would have
to switch to non-blocking mode before the I/O operation is done in
all cases where one wants to make sure one doesn't wait more than a
certain time. Correct?

David, thank you for the free lesson;-)

The result of 'select' is 'a guarantee' that a certain condition
was true at the time 'select' checked it. And this condition will not
'automagically' change on its own. Something needs to change it.
For a file descriptor (minus implementation quirks), this must be
something another process which posesses an open file descriptor
refering to the same resource has done in the meantime.