Subject: Re: M_EXT_PAGES
To: None <firstname.lastname@example.org>
From: Jonathan Stone <email@example.com>
Date: 06/06/2004 11:20:59
In message <200406061444.QAA22759@father.ludd.luth.se>firstname.lastname@example.org writes
>When frobbing the subject - what is happening in the splice() area?
do you have an application for it?
I still hope to implement splice(2) with kcont(9). But we're still
pinning down an, um, an API (I'm avoiding the word "contract" here),
that specifies exactly when it's safe to call soreceive() from a
Then you can build a kcont that uses recvfrom() with a non-NULL struct
mbuf **mp to reads data out of one connected socket, and sendto() to
write it to another socket of the same type (SOCK_DGRAM, SOCK_STREAM,
SOCK_SEQPPACKET). Register the kcont as the sbnotify callback
function of each socket.
It's a little more work than that, since:
a) when a socket becomes readable, you need to check the
peer's receive sbspace() before pulling data out;
similarly, when a socket becomes writable, you need
to check if the peer has ready data but was blocked waiting
for the socket to become ready.
DMR mentions the same underlying issue in the streams paper.
b) NetBSD (4.4-Lite?) has a signle shared callback function
for soreadable/sowritable/exceptions, so you need to fold
all the tests into one monster continuation (callback).
but not really that much more.