🚀 go-pugleaf

heby <heby@poczta.onet.pl> wrote:

> Manula klęczy na kolanach i zapewnia mnie że read w trybie bookującym 
> nigdy nie wyjdzie z innym size niż kiedy jest fatal lub INTR,

Pokaż ten fragment.

Zgodnie z moją wiedzą, mając rurkę możesz dostawać dane w jednostkach 
PIPE_BUF (linux/limits.h, 4096 bajtów).

https://www.gnu.org/software/libc/manual/html_node/Pipe-Atomicity.html

Reading or writing pipe data is atomic if the size of data written is not 
greater than PIPE_BUF. This means that the data transfer seems to be an 
instantaneous unit, in that nothing else in the system can observe a state 
in which it is partially complete. Atomic I/O may not begin right away (it 
may need to wait for buffer space or for data), but once it does begin it 
finishes immediately. 

Reading or writing a larger amount of data may not be atomic; for example, 
output data from other processes sharing the descriptor may be 
interspersed. Also, once PIPE_BUF characters have been written, further 
writes will block until some characters are read. 

https://man7.org/linux/man-pages/man7/pipe.7.html

Tu piszą tylko o nieprzeplataniu danych, ale spodziewałbym się, że dotyczy 
to też "granularności" odczytów.

       POSIX.1 says that write(2)s of less than PIPE_BUF bytes must be
       atomic: the output data is written to the pipe as a contiguous
       sequence.  Writes of more than PIPE_BUF bytes may be nonatomic: the
       kernel may interleave the data with data written by other processes.
       POSIX.1 requires PIPE_BUF to be at least 512 bytes.  (On Linux,
       PIPE_BUF is 4096 bytes.)  The precise semantics depend on whether the
       file descriptor is nonblocking (O_NONBLOCK), whether there are
       multiple writers to the pipe, and on n, the number of bytes to be
       written:

-- 
Pewna położna została zwolniona z pracy. Bawiła się na porodówce
telefonem i miała 20 nieodebranych.