Re: [ANNOUNCEMENT PATCH COW] proof of concept impementation of cowlinks

[Pavel Machek <pavel@ucw.cz>]

Hi!

> > > For years now I've wanted to use a sendfile variant to tell the system to
> > > connect two filehandles from userspace.  Not just web servers want to
> > > marshall data from one filehandle into another, things like netcat want
> > > to do it between a pipe and a network connection, and I've wrote a couple
> > > of data dispatcher daemons that wanted to do it between two network
> > > connections.
> > >
> > > Unfortunately, sendfile didn't work generically when I tried it (back
> > > under 2.4).  Would this infrastructure be a step in the right direction
> > > to eliminate gratuitous poll loops (where nobody but me EVER seems to get
> > > the "shutdown just one half of the connection" thing right.  My netcat
> > > can handle "echo 'GET /' | netcat www.slashdot.org 80".  The standard
> > > netcat can't. Yes, I plan to fix the one in busybox eventually...)
> >
> > Ugh. Yes, some syscalls like that were proposed... but to
> > make programming easier, you'd need asynchronous
> > sendfile to help you with programming, right?
> 
> Doesn't asynchronous sendfile has the little problem your process can exit 
> before the sendfile is complete?

Hmm, it has...

> I'm not sure how much of a help it really is, since fork() isn't brain surgery 
> if you want it to be asynchronous, and the lifetime rules are really explicit 
> then.  (With a ps that does thread grouping, this isn't too bad from a 
> clutter standpoint, even.  And you automatically get a SIGCHLD when the 
> sendfile is complete, too...)

Right.

> Of course if the syscall can make the sendfile outlive the process that fired 
> it off, then by all means it sounds good.  I dunno how much extra work that 
> is for the kernel, though.

Well, it would be "interesting" to stop that sendfile then. You could
not kill it etc.

I guess async sendfile is bad idea after all.
								Pavel
-- 
When do you have heart between your knees?