[lkml]   [2000]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: accept() improvements for rt signals
Julian Anastasov ( wrote:
> 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()
>[has possible races, so]
> 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.

Yep. You're not the first to notice this.
Zach Brown has been finding and working around races just
like this while writing phhttpd. In email to Zach and me, proposed:

> One thing we can do to deal with some of this is to have a new fcntl to
> augment F_SETOWN, FASYNC and F_SETSIG. A F_SETFAST() would perform a
> setsig and a setown at once, _and_ would accept a poll struct into which
> it would fill the current state of the socket. That would provide a
> single-syscall socket setup mechanism which guarantees not to lose any
> events (events that happened before the SETFAST would be returned in the
> poll struct).

Here's another possible race:
User closes fd 5. Events for fd 5 are still in the signal queue.
User does accept(), which returns a new fd 5.

Your proposed new ioctl could eliminate both the race you're worried about
*and* the one I just pointed out if it also delivered a signal that said
"fd 5 created". The user would then discard any events for fd 5
received after the close() but before the "fd 5 created" signal.

That "fd 5 created" signal would tell the user code to reset its
"fd 5 poll status" variable, which would then be updated by the sigio
signals whenever fd 5's poll status changed. No need for an initial
call to poll() or a poll struct * in F_SETFAST then.
- Dan

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.096 / U:0.356 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site