Olhando para o código-fonte, a implementação de pipe_read
em source/fs/pipe.c
mudou bastante no kernel do Linux, mas a partir de uma leitura rápida do código em 2.0.40 , 2.4.37 , 2.6.32 , 3.11 e 4.9 , parece-me que sempre que houve ( ou é, enquanto read
está bloqueando) uma gravação do tamanho w e uma leitura do tamanho r com r > w , então read
retornará pelo menos w bytes. Então, se você tem pedaços de tamanho fixo (de um tamanho menor que PIPE_BUF
) e sempre faz leituras desse mesmo tamanho, então você está na prática garantido para sempre ler um pedaço inteiro.
Por outro lado, se você tem pedaços de tamanho variável, não há essa garantia. Existe uma garantia de atomicidade apenas no lado da escrita: uma gravação de menos que PIPE_BUF
não será cortada por outro gravador. Mas no lado do leitor, se houve e. uma escrita de 10 bytes seguida por uma escrita de 20 bytes, e você depois tenta ler 15 bytes, então você obterá a primeira gravação completa e os primeiros 5 bytes da segunda escrita. A chamada read
não pára de ler os dados até que eles precisem bloquear ou o buffer de saída está cheio.
Se você quiser transmitir dados em partes, use um soquete de datagrama em vez de um canal.