Os shell pipes bloqueiam os processos de origem upstream se o buffer estiver transbordando?

Caso específico

Sim, findbloqueará pelo tempo que for necessário. Um teste "simples" é como:

find / -print -exec sh -c 'printf "%s\\n" "$1" >/dev/tty' find-sh {} \; \
| while </dev/tty read user_input; do read from_find; done

Aqui estão os find -printnomes de caminho para um pipe ( findno seu código faz o mesmo, ele usa implícito -print). Cada nome de caminho é impresso adicionalmente em /dev/tty, para que você o veja depois -print de ser bem- sucedido. Em algum momento a saída que você vê irá bloquear, é quando o buffer do pipe está (quase) cheio. Pressione Enterpara disparar read from_finda leitura do tubo e liberar espaço no buffer.

Provavelmente você precisará pressionar várias vezes Enter(na prática é bom segurar e ser paciente) até findimprimir outro monte de nomes de caminho para /dev/tty. No entanto, ao não pressionar, Entervocê pode findbloquear por um tempo arbitrariamente longo.

Caso Geral

Você escreveu:

Eu quero entender é como o kernel Linux (ou shell?)

O shell é responsável por configurar as coisas: criar processos com descritores (incluindo descritores padrão: stdin, stdout, stderr) conectados aos respectivos arquivos (fifos sem nome, ou seja, pipes; ou arquivos de outros tipos ). Os dados que fluem por um tubo entre processos (como seu finde xargs) não fluem pelo shell. O shell não atua como um relé.

Para entender como os estouros de pipeline são tratados, em geral, você pode obter algumas informações dos seguintes fragmentos da especificação POSIX dewrite() :

DESCRIÇÃO

[…]

As solicitações de gravação em um pipe ou FIFO devem ser tratadas da mesma maneira que um arquivo comum com as seguintes exceções:

[…]

• Se o O_NONBLOCKsinalizador estiver limpo, uma solicitação de gravação pode fazer com que o encadeamento bloqueie, mas na conclusão normal, ele retornará nbyte.

• Se o O_NONBLOCKsinalizador estiver definido, write()as solicitações devem ser tratadas de maneira diferente, das seguintes maneiras:

  • A write()função não deve bloquear o thread.

  […]

[…]

ERROS

[…]

[EAGAIN]
O arquivo é um pipe ou FIFO, o O_NONBLOCKsinalizador é definido para o descritor de arquivo e o encadeamento seria atrasado na operação de gravação.

[…]

JUSTIFICAÇÃO

[…]

Uma tentativa de gravar em um pipe ou FIFO tem várias características principais:

[…]

• Bloqueio/imediato: O bloqueio só é possível com O_NONBLOCKclear. Se houver espaço suficiente para que todos os dados solicitados sejam gravados imediatamente, a implementação deve fazê-lo. Caso contrário, o thread de chamada pode bloquear; ou seja, faça uma pausa até que haja espaço suficiente para escrever. […]

[…]

Isso significa que um thread de escrita pode:

• definido O_NONBLOCKe em caso de espaço insuficiente no buffer, ele obterá [EAGAIN], poderá continuar (com outras tarefas) e, eventualmente, tentar escrever novamente; ou
• claro O_NONBLOCKe em caso de espaço insuficiente no buffer, ele será bloqueado.

Se uma thread de um programa usa write()com O_NONBLOCKset, o programa deve rastrear o que foi escrito com sucesso e o que requer outra tentativa. Com O_NONBLOCKclear, um buffer de pipe estar cheio não é uma preocupação: o thread apenas usa write()e fica bloqueado pelo tempo que for necessário; esse bloqueio acontece write()e não requer nenhum esforço adicional (código), como polling, trap ou qualquer coisa.

read()pode bloquear como write(), a situação é bastante semelhante e não vou elaborar separadamente.

Esse design permite que os programas usem tubos de maneira confiável e fácil. A ideia do pipe é que os escritores esperam por espaço no respectivo buffer, os leitores esperam por algo no respectivo buffer; assim, os dados acabarão fluindo mesmo se houver um gargalo.

É possível escrever um programa impaciente que sairá se não conseguir escrever (quase) imediatamente (ou ler, no caso de um leitor). Programas projetados para trabalhar com tubos devem ser infinitamente pacientes. As ferramentas padrão *nix (incluindo find) por design são infinitamente pacientes¹. É preciso um esforço adicional para criar um programa impaciente ou envolver uma ferramenta padrão do paciente em algo que implemente um tempo limite.

O impasse pode acontecer se o "encanamento" for circular ( exemplo ) ou se ele se ramificar e convergir posteriormente (como aqui ). É um problema separado que tem pouco (ou nada) a ver com a rapidez com que os programas processam dados. Não ocorre em um arranjo linear de tubos.

Consideramos as especificações POSIX de write()e read(). O Linux é classificado como "principalmente compatível com POSIX" . Não é "totalmente compatível", mas não espero que se desvie significativamente do POSIX na área em questão. Tubos de trabalho confiável são muito importantes.

_{¹ Não espero que as implementações consigam bloquear até o fim do Universo, ou além do ano 2038 ou 2147485547 . Por "programa infinitamente paciente" quero dizer um programa que não é deliberadamente impaciente por si só.}

Conclusão

Seu comando está bem como um pipeline. (É falho por outro motivo, veja abaixo.)

Nota

Você find … | xargs rmdir -pse comportará mal para nomes de caminho contendo espaços em branco (como espaços), novas linhas, aspas simples ou duplas, barras invertidas. Isso ocorre porque xargssem opções específicas interpreta estes.

Uma maneira confiável é por find … -print0 | xargs -0 …ou por find … -exec …. Este último é portátil.

find /media/me/disk_with_huge_inode_count -type d -empty -exec rmdir -p {} +

(AFAIK findtambém é infinitamente paciente ao esperar para -execterminar.)