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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 3 Jul 2009 13:42:12 +0800
From:	Changli Gao <xiaosuo@...il.com>
To:	Amerigo Wang <xiyou.wangcong@...il.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: PROPOSAL: extend pipe() to support NULL argument.

On Fri, Jul 3, 2009 at 1:19 PM, Amerigo Wang<xiyou.wangcong@...il.com> wrote:
>
>
> Yes, exactly.
> Inventing a new API is better than modifying pipe(2), IMO.
>
> BUT I still don't agree that you really need this... I think you
> can add a flag or something like that to an fd to do this, e.g.
>
>   fcntl(fd, F_SETFD, FD_PIPERW);
>
> Isn't this better?
You don't understand my need. I don't want to change a RDONLY or
WRONLY pipe to a RW one, but I want to pipe() return just one RW pipe
instead. It seems you prefer pipe0() to pipe(NULL).

>
>>
>>You don't know my meaning. As a proxy server, there maybe lots of
>>connections to maintain, and these connections will keep open for a
>>long time. If the data received can be sent in a relay cycle, the
>>kernel buffer can be reused. If not, the kernel buffer must be
>>reserved. When there are lots of these kinds of connections, lots of
>>kernel buffers must be reserved. At this time, whether two fds per
>>kernel buffer or one fds per kernel buffer matters.
>
> SHow us the code, please.
>
If you don't know my need after reading my words, I don't think you
can understand the fake code. The fake code:

main thread:

while (1) {
   fd = accept();
   pthread_create(worker, fd);
}

worker thread(assume data is transfered just from client to server for
simplification):

serv_fd = connect();
while (1) {
  select(fd, RD);
  pipe = get_pipe_from_poll();
  n = splice(fd, pipe);
  while (n > 0) {
     n -= splice(pipe, serv_fd);
  }
  put_pipe_to_poll();
}
close(serv_fd);
close(fd);

If there are lots of threads blocked on splice(pipe, serv_fd), there
will be lots of kernel buffers.

-- 
Regards，
Changli Gao(xiaosuo@...il.com)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/