lkml.org 
[lkml]   [2003]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: select() stress
    Hi Richard :)

Richard B. Johnson dixit:
> > > descriptors. You cannot assume that this number is the same
> > > as the currently open socket. Just use the socket-value. That's
> > > the file-descriptor.
> > Not at all. 'select()' takes a *number of file descriptors* as
> > its first argument, meaning the maximum number of file descriptors to
> > check (it checks only the first N file descriptors, being 'N' the
> > first argument). Usually that first argument is FD_SETSIZE, but the
> > result of any function returning a number is right if you know that
> > the return value is what you want.
> What I said has been misinterpreted. Select takes the highest
> number fd in the set you want to examine plus 1.

AFAIK, only if the first argument is 'FD_SETSIZE', but I'm not
sure of this point.

And yes, now I understand what you meant, and you're right. If
you put in the set file descriptor 'N', you *must* put in the first
argument at least N+1, or the file descriptor won't be checked.

Anyway, in the case of 'getdtablesize()', and assuming that it
returns the highest 'openable' file descriptor, it will always return
a number that is higher than any open file descriptor that the
process has (except if it's inherited from the parent and the child
has a lower file descriptor limit, but this involves tweaking with
getdtablesize()...), since the fd numbers start from zero.

> They are not the same and are not guaranteed to be related although
> on some target, they might.

That's what I didn't understand with getdtablesize(). In the man
page I can read that the function returns the size of the descriptor
table for the process, not the highest number for a file descriptor,
so you can't use it for 'select()', because you can have a socket
descriptor with value e.g. 40055 open and getdtablesize() will
return, for example, 1024. That is, you can open 1024 file
descriptors in your process, but the open call can return 40000 :?

This leads me to the following thinking: I thought that the code
below is a good way of closing all opened file descriptors, but if
the OS can return an arbitrary number higher than the descriptor
table size for a file descriptor, won't work:

for (i=0; i < getdtablesize(); i++) close(i);

How can this be achieved, knowing that the return value for
getdtablesize() doesn't need to be related with fd numbers (that is,
the kernel can return any arbitrary value for a file descriptor,
given that the limit for OPEN_MAX or getdtablesize() is honored)?

Interesting issue :) Thanks, Richard.

Raúl Núñez de Arenas Coronado

--
Linux Registered User 88736
http://www.pleyades.net & http://www.pleyades.net/~raulnac
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:34    [W:0.078 / U:1.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site