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

[Ian Stirling <ian.stirling@mauve.plus.com>]

Rob Landley wrote:
> On Tuesday 25 May 2004 17:08, Pavel Machek wrote:
> 
> 
>>>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.
> 
> 
> Well, logically what you're doing is redirecting an existing filehandle so it 
> points to something else.  Instead of reading from this pipe, you're now 
> reading from this file or from this network socket, or this other process's 
> stdout.  So any intermediate processes going away is theoretically okay as 
> long as the anchors at each end remain (process/filesystem/network connection 
> generating the data, process/filesystem/network connection receiving the 
> data).
> 
> The easy way to make the semantics work out right is that such an asynchronous 
> sendfile would effectively close the file in question from the point of view 
> of the process that did the sendfile.  It would pretty much have to be part 
> of the semantics of any asynchronous sendfile call: welding together the two 
> filehandles would behave like a single direction shutdown(2) as far as the 
> process that called sendfile is concerned.  (That way, if you do an async 
> sendfile in each direction, the filehandle is closed both ways, but you don't 
> HAVE to if you don't want to.  You can feed data to a child process from a 
> script file or something, and just deal with the responses coming back.)
> 
> This would mean that in theory the process that did the sendfile could go away 
> without too much ambiguity about what should happen.  (The bits that are 
> already closed from the process's point of view are unaffected by the process 
> exiting.)  I dunno what's needed to clean that up in the kernel.
> 
> I also don't know if it's a good idea, because as you noticed the fire and 
> forget nature of the thing means that killing it afterwards is something we 
> haven't got a semantic for if the thing at the other end is NOT a pipe to a 
> processes.  (We kill processes.  We don't have a kill for network connections 
> or for files in the filesystem that are no longer associated with any 
> process.  This is theoretically existing problem, by the way.  Check out 
> SO_LINGER in man 7 socket...)
> 

A while back (2.2?) I was using a util that came with netpipes, sockdown.
Give it a socket FD, and it would close the socket.
It wasn't intended for it, but I found that it was really handy to
be able to shut other programs network connections.
For example, tin gets wedged talking to a server that won't do something, and
you just do
sockdown </proc/tin/fd/nn
And it shuts.

Mildly annoyingly, this stopped working in 2.4.
I suppose it'd be totally insane for init to inherit descriptors for open network
connections.