Consider the asynchronous kernel call
int connectfd(int fd1, int fd2, int options)
fd1 must have read permissions, and fd2 must
have write permissions.
It "connects" fd1 to fd2, i.e pipes data from
fd1 to fd2. Certain transfer characteristics
can be inferred from the open file descriptor
flags, i.e. if fd1 is read only, then data is
piped from fd1 to fd2 until end of file on fd1
or error. If fd1 and fd2 are r/w, then the
data could be piped in both directions.
options could take several constants:
CONFD_BIDIR - force bidirectional data
transfer
CONFD_CLOSE - close fd on completion
..etc as needed
The return value is the fd of a message queue
which returns the status on completion.
This completely removes user buffers from the
picture. We don't need to call mmap() on
files (not that that adds much delay time),
and this works on sockets and pipes as well.
Not only would this help with an HTTP server
case, it would help with many other things
where two fd's are "plugged" together, like
stateless proxies.
A modification of this idea would be to have
an application make a socket() type call,
specifying a protocol family of PF_ASYNC,
which it would receive the completion records
over via recvmsg() calls. I like this
better because then you only have one
notification channel, although for some
applications that might not work as well.
Food for thought,
Zach Amsden
amsden@andrew.cmu.edu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu