From: "Richard B. Johnson" <root@chaos.analogic.com>
To: DervishD <raul@pleyades.net>
Cc: "Sparks, Jamie" <JAMIE.SPARKS@cubic.com>,
Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: select() stress
Date: Tue, 18 Mar 2003 08:06:22 -0500 (EST) [thread overview]
Message-ID: <Pine.LNX.4.53.0303180758380.26753@chaos> (raw)
In-Reply-To: <20030318102837.GH42@DervishD>
On Tue, 18 Mar 2003, DervishD wrote:
> Hi all :)
>
> Richard B. Johnson dixit:
> > > /* ****************************** */
> > > if (select(getdtablesize(), &socklist, NULL, NULL, NULL) < 0)
> > > {
> > > if (errno != EINTR) perror("WeapTerrain");
> > > continue;
> > > }
> > select() takes a file-descriptor as its first argument, not the
> > return-value of some function that returns the number of file-
> > 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.
>
> If, for example, FD_SETSIZE is set to UINT_MAX but
> getdtablesize() returns 100 ('ulimit' came to mind), it's a good idea
> to use the return value of that function. Anyway, IMHO is better to
> use FD_SETSIZE.
>
> See the glibc info for more references.
>
> Bye and happy coding :)
> Raúl Núñez de Arenas Coronado
>
What I said has been misinterpreted. Select takes the highest
number fd in the set you want to examine plus 1. It therefore
requires some relationship to the fd that you are using if
you are using a socket whos value was N you must select on
(at least) N+1, not the return value of a function that gives
the maximum number of fds that you can open. They are not the
same and are not guaranteed to be related although on some
target, they might. It's the same problem as:
write(1, "Hello\n", 6);
Such code is broken. At the very least, one needs to use
STDOUT_FILENO as the fd, and really should not count characters
by hand.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
next prev parent reply other threads:[~2003-03-18 12:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-17 15:28 Sparks, Jamie
2003-03-17 15:43 ` Matti Aarnio
2003-03-17 16:15 ` Richard B. Johnson
2003-03-17 18:00 ` Miquel van Smoorenburg
2003-03-17 18:24 ` Olaf Titz
2003-03-18 10:28 ` DervishD
2003-03-18 13:06 ` Richard B. Johnson [this message]
2003-03-18 14:42 ` DervishD
2003-03-18 14:46 ` DervishD
2003-03-18 14:49 Sparks, Jamie
2003-03-18 15:05 ` Richard B. Johnson
2003-03-18 15:05 ` Sparks, Jamie
2003-03-19 4:18 ` Chris Friesen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.53.0303180758380.26753@chaos \
--to=root@chaos.analogic.com \
--cc=JAMIE.SPARKS@cubic.com \
--cc=linux-kernel@vger.kernel.org \
--cc=raul@pleyades.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®