Re: PROPOSAL: extend pipe() to support NULL argument.

[Amerigo Wang <xiyou.wangcong@gmail.com>]

On Fri, Jul 03, 2009 at 04:27:29PM +0800, Changli Gao wrote:
>On Fri, Jul 3, 2009 at 4:16 PM, Amerigo Wang<xiyou.wangcong@gmail.com> wrote:
>> On Fri, Jul 03, 2009 at 03:40:34PM +0800, Changli Gao wrote:
>>>On Fri, Jul 3, 2009 at 3:15 PM, Amerigo Wang<xiyou.wangcong@gmail.com> wrote:
>>>>
>>>> If saving one fd really helps here, probably you want to
>>>> save more, you will need a syscall like:
>>>>
>>>>  int splice_without_new_fd(int infd, int outfd);
>>>Do you know sendfile()? Its current implementation is buggy, and will
>>>be blocked on outfd. Anyway, the above code is just a use case, there
>>>are other cases sendfile can't cover.
>>
>> So what? So you should fix it intead of inventing a new pipe() and use
>> splice(2)...
>I said: It just a special case. Fixing sendfile() won't fix everything.

What do you want? Just saving an fd, isn't it?

sendfile() does this but you said it's buggy, if you fix it, what is the
rest problem?

>
>>
>> Wait... if splice(2) doesn't block, what is your point for saving
>> an fd in your code? You can do:
>>
>> int splice_two_fd(int fd1, int fd2)
>> {
>>        int fds[2];
>>        pipe(fds);
>>        splice(fd1, fds[0]);//not block
>>        splice(fds[1], fd2);//not block
>>        close(fds[0]); //can be closed soon
>>        close(fds[1]); //ditto
>> }
>>
>> Outside this function no new fd's are used.
>>
>In fact, sendfile(2) is implemented via splice(2) infrastructure. The
>logic is the same, and much clever than yours. Dive into its code, you
>will find the reason why it must be blocked on outfd.


Sure, this is done in user-space, definitely....

>
>>>
>>>>
>>>> But splice(2) is designed to be as it is. You need to increase
>>>> your fd limit, instead of saving one by pipe().
>>>>
>>>I don't agree with you. We should save resource as much as we can, and
>>>not work around it.
>>
>> You are saying splice(2) is wrong? Because it is splice(2) who
>> needs 3 fd's finally.
>>
>It isn't splice(2)'s fault. In fact, I can also work around this issue
>by named pipe.

And increase the max fd number...