socket.socket.settimeout implementation

[jn...@ensim.com]

When using socket.socket.settimeout we normally only guard against
"socket.timeout" exception.Now the implementation of "settimeout" in
"Python-2.4.3/Modules/socketmodule.c" sets the socket fd to
nonblocking and uses "select()" to timeout
as seen below in line 1487 and 1386 :

static PyObject *
1470 sock_settimeout(PySocketSockObject *s, PyObject *arg)
1471 {
1472 double timeout;
..............................
1485
1486 s->sock_timeout = timeout;
1487 internal_setblocking(s, timeout < 0.0);
1488
1489 Py_INCREF(Py_None);
1490 return Py_None;
1491 }
1492

1362 sock_accept(PySocketSockObject *s)
1363 {
...

1385 Py_BEGIN_ALLOW_THREADS
1386 timeout = internal_select(s, 0);
1387 if (!timeout)
1388 newfd = accept(s->sock_fd, (struct sockaddr *)&addrbuf,
1389 &addrlen);
1390 Py_END_ALLOW_THREADS
1391

Now internal_select() returns "1" on timemout else "0" as seen below
:

673 n = select(s->sock_fd+1, &fds, NULL, NULL,&tv);
674 if (n == 0)
675 return 1;
676 return 0;

back to the sock_accept() fuction on line 1387

1387 if (!timeout)
1388 newfd = accept(s->sock_fd, (struct sockaddr *) &addrbuf,
1389 &addrlen)

if "select()" returned before timeout we call "accept()"

Now my observation on FC4 ( kernel version 2.6.11-1.1369_FC4)
"select()" can return before timeout with a
"Interrupted system call" (EINTR) error,

my question is , is it possible that our internal_select() fuction as
seen on line 676 above returns "0" and we go on to do a "accept()" call
which returns with a "Resource temporarily unavailable" error if the
sockfd is not readable. So user expects only "socket.timeout" but gets
"Resource temporarily unavailable" which stops the program
from proceeding.

Our Case : We are using CherryPy , which sets a timeout on socket using
"settimeout" and whenever our code uses "os.seteuid" cherrpy dies
giving
out the "Resource temporarily unavailable".

I did write a "C" program using pthreads , one thread doing
non blocking accept() and select() and other thread doing a seteuid()
.
select() did bail out giving Interrupted system call Error.

Thanks
Jitendra Nair

[Lawrence D'Oliveiro]

In article <1144228868.5...@i40g2000cwc.googlegroups.com>,
jn...@ensim.com wrote:

>Now my observation on FC4 ( kernel version 2.6.11-1.1369_FC4)
>"select()" can return before timeout with a
>"Interrupted system call" (EINTR) error,

Nothing Red-Hat-specific, or even Linux-specific, about this. It's a
standard *nix thing. _All_ potentially time-consuming system calls (such
as select(2), read(2), write(2)) can return EINTR, or some other
indication that they didn't do everything they were asked to do.

<http://en.wikipedia.org/wiki/PCLSRing>

>my question is , is it possible that our internal_select() fuction as
>seen on line 676 above returns "0" and we go on to do a "accept()" call
>which returns with a "Resource temporarily unavailable" error if the
>sockfd is not readable.

The semantics of select(2) is that you're supposed to check the
returrned bitmasks and only take the appropriate actions if the
corresponding read-ready, write-ready and error bits are set.

See the select(2) man page for more on this.