[lkml]   [2000]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subjectaccept() improvements for rt signals


I have played these days with accept() and sigwaitinfo().
It seems that for single threaded server we have to:

1. setup listening socket: O_ASYNC|O_NONBLOCK, SETOWN my_pid,
signals (SIGIO, SIGRTMIN...), etc.

In the loop:

2. accept() the connection
3. fcntl(connected_socket,F_SETFL,O_NONBLOCK|O_ASYNC|O_RDWR)
4. fcntl(connected_socket,F_SETSIG,sig)
5. fcntl(connected_socket,F_SETOWN,again_my_pid)
6. read(connected_socket...), sigwaitinfo()

It is possible between points 2 and 5 the data for
the connected socket to arrive. So, I had to put an extra
read() after F_SETOWN to detect this condition. The reason for
this is that the connected_socket is not owned nor setup for
sigio and the process is not signalled for the received data.
The following sigwaitinfo() after F_SETOWN just blocks if there
are no other active sockets and if we don't use read() to
detect this situation the received data will stay in the
queue. If we have received all data before F_SETOWN, the web
request for example, and if we are not so "smart" to put extra
read(), it is possible this socket to block forever. The
client waits for the server response but the server missed
the notification for the received data.

My proposal: is it possible to add SO_INHERITOWN or other
socket/file (F_COPYOWN) option suitable for listening sockets
with the main goal to let sys_accept() to copy the fd owner after
get_fd(2.2.x) or sock_map_fd(2.3.x) in net/socket.c.

The current behavior will be the default but we can
setup the listening socket (just once) to copy its ownership to
the connected socket. By this way we can eliminate these 4
syscalls (3 fcntl and 1 extra read) for each accepted connection.

This socket option can help for multi threaded servers
too. Any differences?

I haven't made a patch yet. I need more opinions
about this problem. May be I'm wrong? Are there any other
things that can be inherited from the listening socket
using the new option or only the f_owner is enough? Where
the flag will be stored in the socket structure, etc.

Any opinions?


Julian Anastasov <>

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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