1 |
Hello. This might be OT but I am pretty interested in this and being |
2 |
unlucky not able to find a real in-depth explanation of pipe on the |
3 |
Internet. |
4 |
|
5 |
How does pipe actually work? I mean, when there is a pipe like this: |
6 |
$ appA | appB |
7 |
What happen if appA produced output when appB is still busy processing |
8 |
the data and did not require any data from input? |
9 |
|
10 |
possibility 1) as long as appA can get the resource (CPU?), it simply |
11 |
keep outputing data, and this data is cached in memory, as long as there |
12 |
is enough memory, and will finally feed to appB when appB finished his |
13 |
business and begin to accept more data; |
14 |
|
15 |
possibility 2) as long as appB stop requiring data, appA is suspended, |
16 |
the resource goes to appB. appA is only given resource (CPU?) when appB |
17 |
finished his business and begin to accept more data; |
18 |
|
19 |
Which one is true? I know usually 1) and 2) makes no difference to most |
20 |
users, that's why the detail explanation of "1) or 2)" is so hard to |
21 |
google out. |
22 |
|
23 |
In my case appA gets the data from another host who have very short |
24 |
timeout settings, appB is used to compress the data obtained from appA. |
25 |
the compression is very difficult, usually at 30Kbps, the network is |
26 |
very fast, around 10Mbps. appB compress the data tunck by tunck, if |
27 |
Linux actually works in mode 2), the network connection is dropped when |
28 |
the interval of two tuncks of appB compressing data is longer then the |
29 |
network timeout setting. appA acutally don't know how to restart |
30 |
connection from where it was dropped, thus understanding this difference |
31 |
makes sense to me. |
32 |
|
33 |
I made several experiements and my appA and appB both works fine, but I |
34 |
don't dare to share this appA/B to others unless I get the mechnism |
35 |
understood. |
36 |
|
37 |
Thank you in advance. |
38 |
|
39 |
-- |
40 |
gentoo-user@g.o mailing list |