Path: ...!news.mixmin.net!proxad.net!feeder1-2.proxad.net!cleanfeed1-a.proxad.net!nnrp1-1.free.fr!not-for-mail
Newsgroups: fr.comp.os.linux.configuration
From: Nicolas George <nicolas$george@salle-s.org>
Subject: Re: =?iso-8859-1?Q?Probl=E8mes_bizarres_de_lecture_dans_un_pipe_=28en_C=29?=
 =?iso-8859-1?Q?=2E?=
Sender: george@phare.invalid (Nicolas George)
X-Newsreader: Flrn (0.9.20070704)
References: <tnab3h$h7v$1@cabale.usenet-fr.net> <6398c186$0$24817$426a74cc@news.free.fr> <tnagqb$jpi$1@cabale.usenet-fr.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=utf-8
Date: 14 Dec 2022 09:37:57 GMT
Lines: 52
Message-ID: <63999974$0$3182$426a74cc@news.free.fr>
Organization: Guest of ProXad - France
NNTP-Posting-Date: 14 Dec 2022 10:37:57 CET
NNTP-Posting-Host: 129.199.129.80
X-Trace: 1671010677 news-3.free.fr 3182 129.199.129.80:46304
X-Complaints-To: abuse@proxad.net
Bytes: 3558

Olivier Miakinen , dans le message <tnagqb$jpi$1@cabale.usenet-fr.net>,
 a écrit :
> Sur d'autres machines avec le même programme, quand on dit qu'on est
> capable de lire 10 000 octets et qu'il y en a déjà 30 000 en attente,
> le read retourne bien 10 000 octets. Je ne vois pas pourquoi il serait
> souhaitable de n'en retourner que 4 096 si tout le monde est d'accord
> pour 10 000.
> 
> Ce qui n'empêche pas de boucler, bien sûr, pour récupérer les 20 000
> octets qui restent (voire plus lorsque le fils continue à fournir).

Effectivement, j'ai lu un peu trop vite. Ce que tu décris est un
comportement acceptable mais pas souhaitable.

Mais ça ne correspond pas non plus à ce que j'observe, avec :

{ strace -Tttt -o /dev/pts/14 perl -e '$| = 1; syswrite STDOUT, "X" x 30000'; sleep 2 } | strace -Tttt -o /dev/pts/15 perl -e 'sysread STDIN, $buf, 40000'

… je vois :

1671009300.373032 write(1, "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"..., 30000) = 30000 <0.000018>
1671009300.372976 read(0, "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"..., 40000) = 30000 <0.000089>

Donc le read se satisfait des 30000 sans attendre les 40000 (souhaitable),
mais lit quand même plus que 4096.

(Ne me demande pas pourquoi le timestamp prétend que read() s'est terminé
avant que write() commence.)

> Un exemple minimal, pas vraiment, mais oui je peux montrer un strace.
> En fait je peux même montrer une analyse minimale d'un strace qui
> n'était pas du tout minimal.
> 
> Dans les traces qui suivent, j'ai supprimé tout que ce n'est pas un
> write(8, ...) du fils ou un read(7, ...) du père, et j'ai réordonné
> les lignes pour que chaque read() suive le write() correspondant,
> mais j'ai laissé le numéro de ligne de la trace d'origine. On voit
> donc en premier le numéro de ligne (de 253 à 334), en second le
> PID (4955 pour le père, 4956 pour le fils), puis le read ou le
> write avec les premiers octets en hexadécimal.

Mais que vois-tu de suspect dans ce strace ?

Je fais un essai de mon côté :

strace -Tttt -o /dev/pts/14 perl -e '$| = 1; syswrite STDOUT, "X" x 4096 . "Y" x 4096' | strace -Tttt -o /dev/pts/15 perl -e 'sysread STDIN, $buf, 4090; sysread STDIN, $buf, 4000;'

1671010596.009083 write(1, "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"..., 8192) = 8192 <0.000011>
1671010596.009071 read(0, "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"..., 4090) = 4090 <0.000027>
1671010596.009115 read(0, "XXXXXXYYYYYYYYYYYYYYYYYYYYYYYYYY"..., 4000) = 4000 <0.000008>

On voit bien que le 2e read a reçu les 6 X qui restaient.