.\" -*- coding: UTF-8 -*-
.\" Copyright (C) 2005 Michael Kerrisk <mtk.manpages@gmail.com>
.\"
.\" SPDX-License-Identifier: Linux-man-pages-copyleft
.\"
.\"*******************************************************************
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
.TH pipe 7 "16 lipca 2023 r." "Linux man\-pages 6.05.01" 
.SH NAZWA
pipe \- przegląd potoków i FIFO
.SH OPIS
Potoki i FIFO (zwane również potokami nazwanymi lub łączami nazwanymi)
udostępniają jednokierunkowy kanał komunikacji międzyprocesowej. Potok ma
\fIkoniec do odczytu\fP oraz \fIkoniec do zapisu\fP. Dane zapisane do końca do
zapisu mogą być odczytane z końca do odczytu potoku.
.PP
Potok tworzy się za pomocą \fBpipe\fP(2), które tworzy nowy potok i zwraca dwa
deskryptory plików, jeden odnoszący się do końca do odczytu potoku, a drugi
odnoszący się do końca do zapisu. Potoków można użyć do utworzenia kanału
komunikacji pomiędzy powiązanymi procesami; zob. \fBpipe\fP(2) aby zapoznać się
z przykładem.
.PP
FIFO (skrót od ang. First In First Out \[en] pierwszy na wejściu, pierwszy
na wyjściu) posiada nazwę w systemie plików (utworzoną za pomocą
\fBmkfifo\fP(3)) i jest otwierany przy użyciu \fBopen\fP(2). Każdy proces może
otworzyć FIFO, o ile uprawnienia pliku na to zezwalają. Koniec do odczytu
otwiera się za pomocą znacznika \fBO_RDONLY\fP; koniec do zapisu, za pomocą
\fBO_WRONLY\fP. Więcej szczegółów w podręczniku \fBfifo\fP(7). \fIUwaga\fP: Choć FIFO
mają ścieżkę w systemie plików, to wejście/wyjście na FIFO nie przeprowadza
operacji na podległym urządzeniu (jeśli takie istnieje).
.SS "Wejście/wyjście na potokach i FIFO"
Jedyna różnica pomiędzy potokami i FIFO polega na sposobie ich tworzenia i
otwierania. Po ukończeniu tych zadań, wejście/wyjście na potokach i FIFO
korzysta z dokładnie tej samej semantyki.
.PP
Gdy proces spróbuje odczytać z pustego potoku, \fBread\fP(2) zablokuje do
momentu pojawienia się danych. Gdy proces spróbuje zapisać do pełnego potoku
(zob. niżej), \fBwrite\fP(2) zablokuje do momentu odczytania wystarczającej
ilości danych z potoku, umożliwiającej poprawne przeprowadzenie zapisu.
.PP
Nieblokujące wejście/wyjście można uzyskać za pomocą operacji \fBF_SETFL\fP
\fBfcntl\fP(2), w celu włączenia znacznika statusu otwartego pliku
\fBO_NONBLOCK\fP lub otwierając \fBfifo\fP(7) z \fBO_NONBLOCK\fP. Jeśli jakiś proces
otworzy potok do zapisu, odczyt zawiedzie z błędem \fBEAGAIN\fP; w innych
przypadkach, przy braku potencjalnych zapisujących, odczyt powiedzie się i
powróci pusty.
.PP
Kanał udostępniany przez potok jest \fIstrumienien bajtów\fP: nie występuje
koncept granic komunikatów.
.PP
Jeśli wszystkie deskryptory pliku odnoszące się do końca do zapisu potoku
zostaną zamknięte, to próba odczytu za pomocą \fBread\fP(2) z potoku przyniesie
koniec\-pliku (\fBread\fP(2) zwróci 0). Jeśli wszystkie deskryptory pliku
odnoszące się do końca do odczytu zostaną zamknięte, to zapis za pomocą
\fBwrite\fP(2) spowoduje wygenerowanie sygnału \fBSIGPIPE\fP dla wywołującego
procesu. Jeśli proces wywołujący zignoruje ten sygnał, to \fBwrite\fP(2)
zawiedzie z błędem \fBEPIPE\fP. Aplikacje używające \fBpipe\fP(2) i \fBfork\fP(2)
powinny korzystać z odpowiednich wywołań \fBclose\fP(2), aby zamykać
niepotrzebnie zduplikowane deskryptory pliku; to zapewni, że koniec\-pliku i
\fBSIGPIPE\fP/\fBEPIPE\fP są dostarczane tam, gdzie to konieczne.
.PP
Do potoku nie da się zastosować \fBlseek\fP(2).
.SS "Pojemność potoku"
Potok ma ograniczoną pojemność. Po zapełnieniu potoku, \fBwrite\fP(2) zablokuje
lub zawiedzie, w zależności od tego, czy znacznik \fBO_NONBLOCK\fP jest
ustawiony (zob. niżej). Różne implementacje posiadają odmienne limity
pojemności potoku. Aplikacje nie powinny zależeć od jakiejś określonej
pojemności, lecz należy je zaprojektować tak, aby konsumowały dane tak
wcześnie jak to możliwe, w celu uniknięcia blokowania procesu zapisującego.
.PP
Przed Linuksem 2.6.11, pojemność potoku była taka sama jak systemowy rozmiar
strony (np. 4096 bajtów na architekturze i386). Od Linuksa 2.6.11, pojemność
potoku wynosi 16 stron (tj. 65\ 536 bajtów w systemie o rozmiarze strony
4096 bajtów). Od Linuksa 2.6.35, domyślny rozmiar potoku wynosi 16 stron,
ale można go odpytać i ustawić za pomocą operacji \fBF_GETPIPE_SZ\fP i
\fBF_SETPIPE_SZ\fP \fBfcntl\fP(2). Więcej szczegółów w podręczniku \fBfcntl\fP(2).
.PP
Następująca operacja \fBioctl\fP(2), którą można zastosować do deskryptora
pliku, odnoszącego się do dowolnego końca potoku, umieszcza licznik
nieodczytanych bajtów w potoku, w buforze \fIint\fP wskazanym ostatnim
argumentem wywołania:
.PP
.in +4n
.EX
ioctl(fd, FIONREAD, &nbytes);
.EE
.in
.PP
.\"
Operacja \fBFIONREAD\fP nie jest przewidziana żadnym standardem, ale udostępnia
ją wiele implementacji.
.SS "Pliki /proc"
W Linuksie, następujące pliki kontrolują wielkość pamięci, jaką można
przeznaczyć potokom:
.TP 
\fI/proc/sys/fs/pipe\-max\-pages\fP (tylko w Linuksie 2.6.34)
.\" commit b492e95be0ae672922f4734acf3f5d35c30be948
Górny limit pojemności, podany w stronach, jaką nieuprzywilejowany
użytkownik (nieposiadający przywileju (ang. capability)
\fBCAP_SYS_RESOURCE\fP), może ustawić dla potoku.
.IP
Domyślna wartość tego limitu to szesnastokrotność domyślnego rozmiaru potoku
(zob. wyżej); dolny limit to dwie strony.
.IP
Interfejs ten usunięto w Linuksie 2.6.35, na korzyść
\fI/proc/sys/fs/pipe\-max\-size\fP.
.TP 
\fI/proc/sys/fs/pipe\-max\-size\fP (od Linuksa 2.6.35)
.\" commit ff9da691c0498ff81fdd014e7a0731dab2337dac
.\" This limit is not checked on pipe creation, where the capacity is
.\" always PIPE_DEF_BUFS, regardless of pipe-max-size
Maksymalny rozmiar (w bajtach) poszczególnych potoków, jaki może być
ustawiany przez użytkowników bez przywileju \fBCAP_SYS_RESOURCE\fP. Wartość
przypisana do tego pliku może być zaokrąglona w górę, w uwzględnieniu
wartości użytej faktycznie, ze względu na wygodę implementacji. Aby
sprawdzić wartość zaokrągloną, należy wyświetlić wartość tego pliku, po
przypisaniu mu wartości.
.IP
Domyślną wartością pliku jest 1048576 (1\ MiB). Minimalną wartością, jaką
można przypisać do tego pliku, jest systemowy rozmiar strony. Próby
ograniczenia limitu poniżej rozmiaru strony spowodują niepowodzenie
\fBwrite\fP(2) z błędem \fBEINVAL\fP.
.IP
.\" commit 086e774a57fba4695f14383c0818994c0b31da7c
Od Linuksa 4.9, wartość pliku działa również jako górny, domyślny limit
pojemności nowego potoku lub nowo otwartego FIFO.
.TP 
\fI/proc/sys/fs/pipe\-user\-pages\-hard\fP (od Linuksa 4.5)
.\" commit 759c01142a5d0f364a462346168a56de28a80f52
Bezwzględny limit całkowitego rozmiaru (w stronach) wszystkich potoków
utworzonych lub ustawionych przez pojedynczego nieuprzywilejowanego
użytkownika (tzn. nieposiadającego przywilejów \fBCAP_SYS_RESOURCE\fP ani
\fBCAP_SYS_ADMIN\fP). Gdy całkowita liczba stron przypisanych do buforów potoku
dla danego użytkownika osiągnie tej limit, próby tworzenia nowych potoków
będą odmawiane, a także próby zwiększenia rozmiaru potoku będą odmawiane.
.IP
.\" The default was chosen to avoid breaking existing applications that
.\" make intensive use of pipes (e.g., for splicing).
Gdy wartość limitu wynosi zero (tak jest domyślnie), bezwzględny limit nie
obowiązuje.
.TP 
\fI/proc/sys/fs/pipe\-user\-pages\-soft\fP (od Linuksa 4.5)
.\" commit 759c01142a5d0f364a462346168a56de28a80f52
Miękki limit całkowitego rozmiaru (w stronach) wszystkich potoków
utworzonych lub ustawionych przez pojedynczego nieuprzywilejowanego
użytkownika (tzn. nieposiadającego przywilejów \fBCAP_SYS_RESOURCE\fP ani
\fBCAP_SYS_ADMIN\fP). Gdy całkowita liczba stron przypisanych do buforów potoku
dla danego użytkownika osiągnie tej limit, poszczególne potoki tworzone
przez użytkownika będą ograniczone do jednej strony, a próby zwiększenia
rozmiaru potoku będą odmawiane.
.IP
Gdy wartość limitu wynosi zero, miękki limit nie obowiązuje. Domyślną
wartością tego pliku jest 16384, co pozwala na tworzenie do 1024 potoków o
domyślnym rozmiarze.
.PP
.\"
Przed Linuksem 4.9 pewne błędy wpływały na obsługę limitów
\fIpipe\-user\-pages\-soft\fP i \fIpipe\-user\-pages\-hard\fP; zob. USTERKI.
.SS PIPE_BUF
POSIX.1 określa, że zapis mniej niż \fBPIPE_BUF\fP bajtów musi być
niepodzielny: dane wyjściowe są zapisywane do potoku jako ciągła
sekwencja. Zapis więcej niż \fBPIPE_BUF\fP nie musi być niepodzielny: jądro
może przeplatać dane, z danymi zapisywanymi przez inne procesy. POSIX.1
wymaga, aby \fBPIPE_BUF\fP miał co najmniej 512 bajtów (w Linuksie \fBPIPE_BUF\fP
ma 4096 bajtów). Dokładna semantyka zależy od tego, czy deskryptor pliku
jest nieblokujący (\fBO_NONBLOCK\fP), czy występuje wiele zapisów do potoku
oraz od \fIn\fP, liczby bajtów do zapisania:
.TP 
\fBO_NONBLOCK\fP wyłączone, \fIn\fP <= \fBPIPE_BUF\fP
Wszystkie \fIn\fP bajtów jest zapisane niepodzielnie; \fBwrite\fP(2) może
zablokować, jeśli brak miejsca do natychmiastowego zapisu \fIn\fP bajtów
.TP 
\fBO_NONBLOCK\fP włączone, \fIn\fP <= \fBPIPE_BUF\fP
Jeśli jest miejsce na zapisanie \fIn\fP bajtów do potoku, to \fBwrite\fP(2)
natychmiast powiedzie się, zapisując wszystkie \fIn\fP bajtów; w przeciwnym
wypadku \fBwrite\fP(2) zawodzi, z \fIerrno\fP ustawionym na \fBEAGAIN\fP.
.TP 
\fBO_NONBLOCK\fP wyłączone, \fIn\fP > \fBPIPE_BUF\fP
Zapis jest podzielny: dane przekazane do \fBwrite\fP(2) mogą ulec przepleceniu
z \fBwrite\fP(2) innych procesów; \fBwrite\fP(2) blokuje do momentu zapisania \fIn\fP
bajtów.
.TP 
\fBO_NONBLOCK\fP włączone, \fIn\fP > \fBPIPE_BUF\fP
Gdy potok jest pełny, \fBwrite\fP(2) zawiedzie z \fIerrno\fP ustawionym na
\fBEAGAIN\fP. W przeciwnym wypadku, zapisanych może ulec od 1 do \fIn\fP bajtów
(tzn. może wystąpić \[Bq]częściowy zapis\[rq], wywołujący powinien sprawdzić
wartość zwróconą przez \fBwrite\fP(2), aby przekonać się, jak wiele bajtów
faktycznie zapisano), bajty te mogą być przeplatane z zapisami z innych
procesów.
.SS "Znaczniki statusu otwartego pliku"
Jedyne znaczniki statusu otwartego pliku, jakie można sensownie zastosować
do potoku lub FIFO to \fBO_NONBLOCK\fP i \fBO_ASYNC\fP.
.PP
Ustawienie znacznika \fBO_ASYNC\fP na końcu do odczytu potoku powoduje
wygenerowanie sygnału (domyślnie \fBSIGIO\fP), gdy nowe wejście stanie się
dostępne na potoku. Cel dostarczenia sygnałów należy ustawić za pomocą
polecenia \fBF_SETOWN\fP \fBfcntl\fP(2). W Linuksie \fBO_ASYNC\fP jest obsługiwane w
przypadku potoków i FIFO dopiero od Linuksa 2.6.
.SS "Uwagi dotyczące przenośności"
W niektórych systemach (ale nie w Linuksie), potoki są dwukierunkowe: dane
mogą być transmitowane w obu kierunkach pomiędzy węzłami końcowymi. POSIX.1
wymaga jedynie potoków jednokierunkowych. Przenośne aplikacje powinny unikać
polegania na semantyce potoków dwukierunkowych.
.SS USTERKI
.\" These bugs where remedied by a series of patches, in particular,
.\" commit b0b91d18e2e97b741b294af9333824ecc3fadfd8 and
.\" commit a005ca0e6813e1d796a7422a7e31d8b8d6555df1
Przed Linuksem 4.9 występowały pewne błędy dotyczące obsługi limitów
\fIpipe\-user\-pages\-soft\fP i \fIpipe\-user\-pages\-hard\fP przy używaniu operacji
\fBF_SETPIPE_SZ\fP \fBfcntl\fP(2) do zmiany rozmiaru potoku:
.IP (a) 5
Przy zwiększaniu rozmiaru potoku, sprawdzenia dotyczące limitów miękkich i
bezwzględnych, czynione były wobec istniejącej zajętości i z wyłączeniem
pamięci wymaganej do zwiększenia pojemności potoku. Nowo powiększona
pojemność potoku mogła wykroczyć (nawet znacznie) poza całkowitą pamięć
używaną przez potoki użytkownika (mogło to również wyzwolić problem opisany
jako następny).
.IP
Od Linuksa 4.9, sprawdzenia limitów wliczają pamięć potrzebną do nowej
pojemności potoku.
.IP (b)
Sprawdzenia limitów dokonywano nawet wówczas, gdy nowa pojemność potoków
była niższa niż istniejąca. Mogło to prowadzić do problemów, gdy użytkownik
ustawił znaczną pojemność potoku, a następnie limity ograniczono, co
powodowało, że użytkownik nie mógł już zmniejszyć pojemności potoku.
.IP
Od Linuksa 4.9, sprawdzenia limitów następują tylko przy zwiększaniu
pojemności potoku; użytkownik nieuprzywilejowany może zawsze zmniejszyć
pojemność potoku.
.IP (c)
Wyliczanie i sprawdzanie limitów odbywało się w następujący sposób:
.RS
.IP (1) 5
.PD 0
Sprawdzenie, czy użytkownik przekroczył limit.
.IP (2)
Utworzenie nowego przydzielenia buforu potoku.
.IP (3)
Wyliczenie nowego przydzielenia wobec limitów.
.PD
.RE
.IP
Była to sytuacja sprzyjająca hazardowi. Punkt (1) mogło przekroczyć
jednocześnie wiele procesów, a przydzielone następnie bufory potoku były
wyliczane jedynie w kroku (3), co mogło prowadzić do przekroczenia limitu
przez przydzielony bufor potoku użytkownika.
.IP
Od Linuksa 4.9, krok wyliczania jest dokonywany przed przydzieleniem, a
operacja zawodzi, gdy limit miałby być przekroczony.
.PP
Przed Linuksem 4.9, błędy podobne do opisanych w punktach (a) i (c) mogły
występować również przy przydzielaniu przez jądro pamięci buforowi nowego
potoku tj. przy wywoływaniu \fBpipe\fP(2) i przy otwieraniu uprzednio
nieotwartego FIFO.
.SH "ZOBACZ TAKŻE"
\fBmkfifo\fP(1), \fBdup\fP(2), \fBfcntl\fP(2), \fBopen\fP(2), \fBpipe\fP(2), \fBpoll\fP(2),
\fBselect\fP(2), \fBsocketpair\fP(2), \fBsplice\fP(2), \fBstat\fP(2), \fBtee\fP(2),
\fBvmsplice\fP(2), \fBmkfifo\fP(3), \fBepoll\fP(7), \fBfifo\fP(7)
.PP
.SH TŁUMACZENIE
Autorami polskiego tłumaczenia niniejszej strony podręcznika są:
Michał Kułach <michal.kulach@gmail.com>
.
.PP
Niniejsze tłumaczenie jest wolną dokumentacją. Bliższe informacje o warunkach
licencji można uzyskać zapoznając się z
.UR https://www.gnu.org/licenses/gpl-3.0.html
GNU General Public License w wersji 3
.UE
lub nowszej. Nie przyjmuje się ŻADNEJ ODPOWIEDZIALNOŚCI.
.PP
Błędy w tłumaczeniu strony podręcznika prosimy zgłaszać na adres listy
dyskusyjnej
.MT manpages-pl-list@lists.sourceforge.net
.ME .
