From: Denys Vlasenko <vda.linux@googlemail.com>
To: Albert ARIBAUD <albert.aribaud@free.fr>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Changli Gao <xiaosuo@gmail.com>,
Amerigo Wang <xiyou.wangcong@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: PROPOSAL: extend pipe() to support NULL argument.
Date: Tue, 7 Jul 2009 06:43:56 +0200 [thread overview]
Message-ID: <200907070643.56394.vda.linux@googlemail.com> (raw)
In-Reply-To: <4A4DDD54.9030206@free.fr>
On Friday 03 July 2009 12:28, Albert ARIBAUD wrote:
> Changli Gao a écrit :
>
> > Yea, in many cases, max fd number must be enlarged. More fds means
> > more memory. Although memory is cheaper today, we have to do our best
> > to save money.
>
> Sorry for interrupting, but I don't see how pipe could return a single fd,
> considering there are two (partly) independent ends, each being read (resp.
> written) in their own time, and an fd has only one "current read/write
> position" IIUC.
>
> If the proposal is to have two independent positions (one for reads and one
> for writes) for a single fd, then I am not sure the gain in the number of
> fds used is worth the loss in the increased size of the fd structure.
>
> Am I missing something?
As I understand it, the proposal is to make pipe(NULL) return a fd,
which can be read from and written to. Whatever you write
is remembered, and can be retrieved by reads later.
standard pipe(two_fds) returns two fds. One is only used for writes.
Another is only used for reads. Which may be wasteful in some
situations (like, if you have thousands of pipes).
There is no trick I know of which may be used to "combine"
these two fds into one, close second one and thus save one fd table slot.
--
vda
next prev parent reply other threads:[~2009-07-07 4:40 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-02 7:36 PROPOSAL: extend pipe() to support NULL argument Changli Gao
2009-07-02 9:13 ` Amerigo Wang
2009-07-02 9:18 ` Changli Gao
2009-07-02 9:46 ` Amerigo Wang
2009-07-02 10:04 ` Changli Gao
2009-07-02 10:21 ` Amerigo Wang
2009-07-03 0:43 ` Changli Gao
2009-07-03 1:55 ` Amerigo Wang
2009-07-03 2:10 ` Changli Gao
2009-07-03 3:00 ` Amerigo Wang
2009-07-03 4:08 ` Changli Gao
2009-07-03 5:19 ` Amerigo Wang
2009-07-03 5:42 ` Changli Gao
2009-07-03 7:15 ` Amerigo Wang
2009-07-03 7:40 ` Changli Gao
2009-07-03 8:16 ` Amerigo Wang
2009-07-03 8:27 ` Changli Gao
2009-07-03 9:42 ` Amerigo Wang
2009-07-03 9:59 ` Changli Gao
2009-07-03 10:23 ` Amerigo Wang
2009-07-03 10:28 ` Albert ARIBAUD
2009-07-06 1:12 ` Changli Gao
2009-07-06 6:15 ` Albert ARIBAUD
2009-07-06 6:23 ` Changli Gao
2009-07-06 6:30 ` Albert ARIBAUD
2009-07-07 4:43 ` Denys Vlasenko [this message]
2009-07-07 7:45 ` Changli Gao
2009-07-07 20:37 ` David Newall
2009-07-07 21:02 ` Zan Lynx
2009-07-08 4:41 ` Changli Gao
2009-07-08 4:43 ` David Newall
2009-07-02 10:42 ` Alan Cox
2009-07-03 0:45 ` Changli Gao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200907070643.56394.vda.linux@googlemail.com \
--to=vda.linux@googlemail.com \
--cc=albert.aribaud@free.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=xiaosuo@gmail.com \
--cc=xiyou.wangcong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox