Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Mar 1999 12:12:14 -0800
From:      "Ronald F. Guilmette" <rfg@monkeys.com>
To:        questions@freebsd.org
Subject:   Is select(2) a liar?
Message-ID:  <5797.922133534@monkeys.com>

next in thread | raw e-mail | index | archive | help


Somewhere, burried deep in the bowels of the code for the utility program
called strobe(1), I have seen the following code.

Pay particular attention to the comment in this code.

---------------------------------------------------------------------
    ...
    timeout.tv_sec = 0;
    timeout.tv_usec = 50;
    switch (select (FD_SETSIZE, &set_sel_r, &set_sel_w, 0, &timeout))
    {
    case -1:
        perror ("select");
        return 0;
    case 0:
        return 1;
    }
    for (n = 0; n < a_sock_max; n++)
    {
        h = &attempt[n];
        if (h->status & HT_CONNECTING)
        {
            if (FD_ISSET (h->sfd, &set_sel_r) || FD_ISSET (h->sfd, &set_sel_w))
            {
                struct sockaddr_in in;
                int len = sizeof (in);
                /* select() lies occasionaly
                 */
                if (getpeername (h->sfd, (struct sockaddr *) &in, &len) == 0)
                    gatherer_tcp (h);
                else
                    attempt_clear (h);
            } 
        }
    }
    return 1;
    ...
---------------------------------------------------------------------

The comment in this code says that ``select() lies occasionaly'' (sp).

In my own experience, it seems that this assertion may indeed be true...
under FreeBSD at least.

I need to understand why this might be the case, and what to do about it
(in some other code I am writing).

Given a stream (TCP) socket which you have started an asynchronous (non-
blocking) connect for, if a call to select(2) tells you that the socket is
now writable, what conditions (other than an outright rejection of the
connection attempt by the peer you were connecting to) might cause a
subsequent call to getpeername() to return a -1 error result?  In other
words, what are the precise conditions under which select() will in fact
``lie'' and say that the socket is writable when in fact it is NEITHER
in a connected state nor in an error state?

-- Ron Guilmette, Roseville, California ---------- E-Scrub Technologies, Inc.
-- Deadbolt(tm) Personal E-Mail Filter demo: http://www.e-scrub.com/deadbolt/
-- Wpoison (web harvester poisoning) - demo: http://www.e-scrub.com/wpoison/

    "Ping can be used offensively, and it's shipped with every windows CD"
                                                  -- Steve Atkins


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5797.922133534>