It's mode 2. When appB stops reading, appA will continue writing until the pipe is full (about 4k I believe) at which time appA will block in a write.
dcm On 6/14/06, 张�|武 <[EMAIL PROTECTED]> wrote:
Hello. This might be OT but I am pretty interested in this and being unlucky not able to find a real in-depth explanation of pipe on the Internet. How does pipe actually work? I mean, when there is a pipe like this: $ appA | appB What happen if appA produced output when appB is still busy processing the data and did not require any data from input? possibility 1) as long as appA can get the resource (CPU?), it simply keep outputing data, and this data is cached in memory, as long as there is enough memory, and will finally feed to appB when appB finished his business and begin to accept more data; possibility 2) as long as appB stop requiring data, appA is suspended, the resource goes to appB. appA is only given resource (CPU?) when appB finished his business and begin to accept more data; Which one is true? I know usually 1) and 2) makes no difference to most users, that's why the detail explanation of "1) or 2)" is so hard to google out. In my case appA gets the data from another host who have very short timeout settings, appB is used to compress the data obtained from appA. the compression is very difficult, usually at 30Kbps, the network is very fast, around 10Mbps. appB compress the data tunck by tunck, if Linux actually works in mode 2), the network connection is dropped when the interval of two tuncks of appB compressing data is longer then the network timeout setting. appA acutally don't know how to restart connection from where it was dropped, thus understanding this difference makes sense to me. I made several experiements and my appA and appB both works fine, but I don't dare to share this appA/B to others unless I get the mechnism understood. Thank you in advance. -- gentoo-user@gentoo.org mailing list
-- gentoo-user@gentoo.org mailing list
