socket.socket.settimeout implementation

[jnair@ensim.com]

When using socket.socket.s ettimeout 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 (PySocketSockOb ject *s, PyObject *arg)
1471 {
1472 double timeout;
............... ...............
1485
1486 s->sock_timeout = timeout;
1487 internal_setblo cking(s, timeout < 0.0);
1488
1489 Py_INCREF(Py_No ne);
1490 return Py_None;
1491 }
1492

1362 sock_accept(PyS ocketSockObject *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_TH READS
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
"Interrupte d 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]

Re: socket.socket.s ettimeout implementation

In article <1144228868.576 227.186500@i40g 2000cwc.googleg roups.com>,
jnair@ensim.com wrote:
[color=blue]
>Now my observation on FC4 ( kernel version 2.6.11-1.1369_FC4)
>"select()" can return before timeout with a
>"Interrupte d system call" (EINTR) error,[/color]

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.or g/wiki/PCLSRing>
[color=blue]
>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.[/color]

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.