.\" -*- coding: UTF-8 -*- .\" Copyright (C) 2005 Michael Kerrisk .\" .\" SPDX-License-Identifier: Linux-man-pages-copyleft .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH pipe 7 "2 maja 2024 r." "Linux man\-pages 6.9.1" .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. .P 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. .P 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. .P 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. .P 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. .P Kanał udostępniany przez potok jest \fIstrumienien bajtów\fP: nie występuje koncept granic komunikatów. .P 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. .P 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. .P 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). .P 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: .P .in +4n .EX ioctl(fd, FIONREAD, &nbytes); .EE .in .P .\" 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. .P .\" 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. .P 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. .P 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 Tłumaczenie niniejszej strony podręcznika: Michał Kułach . .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 .