Hi,
On Tue, 22 Feb 2000 14:20:48 +0100, Jamie Lokier
<lk@tantalophile.demon.co.uk> said:
> On that theme, the form of accept2() where you provide a pre-prepared
> socket recycled from a previously shut down client has another
> scalability advantage:
> The kernel does not have to search the fd array to find the smallest
> free fd value.
Genuis. Pure genuis. Another bottleneck hits the dust. :)
This looks pretty simple to achieve: an accept6() modelled after clone,
indicating exactly what properties of the old socket to inherit. A
first attempt looks like:
int accept (int oldfd, struct sockaddr *, int *addrlen,
int newfd, pid_t sigpid, unsigned int clone_flags)
newfd will be the fd we use for the new socket (with precisely the same
semantics as dup2); sigpid will be the pid to which we grant ownership
of the new socket (allowing us to load-balance between threads); and
clone_flags will be a bitmap indicating what properties of the original
socket we want to copy to the new one, including the obvious ones:
SOCKCLONE_ASYNC
SOCKCLONE_NONBLOCK
SOCKCLONE_CORK
SOCKCLONE_LINGER
SOCKCLONE_RBUF
SOCKCLONE_WBUF
SOCKCLONE_SIG
plus a possible new function,
SOCKCLONE_POLLNEW
to place a POLLNEW marker into the siginfo stream.
This can all be done entirely atomically, guaranteeing no dropped
siginfo events on the accepted socket, and if POLLNEW is requested then
we can automatically generate a POLL_IN bit in the si_band bitmap to
indicate that there is something waiting to be read on the new socket.
This shouldn't need a new method in the sock ops, with the possible
exception of dealing with protocol-specific inheritance of things like
the tcp cork settings. We can achieve this functionality on top of the
existing bits and pieces: making the syscall atomic can be done by
ordering things carefully and calling the sock->ops->poll method once
the new socket is established. sock->ops->accept already works on
sockets, not on fds, so any new syscall would be free to implement its
own way of returning the fd --- the dup2 functionality is easy,
therefore.
I'd like the comments of somebody more familiar with the socket stack,
though.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:31 EST