Path: ...!news.mixmin.net!proxad.net!feeder1-2.proxad.net!usenet-fr.net!.POSTED!not-for-mail From: Olivier Miakinen Newsgroups: fr.comp.os.linux.configuration Subject: =?UTF-8?Q?Re:_Probl=c3=a8mes_bizarres_de_lecture_dans_un_pipe_=28en?= =?UTF-8?Q?_C=29.?= Date: Tue, 13 Dec 2022 19:38:02 +0100 Organization: There's no cabale Lines: 75 Message-ID: References: <6398c186$0$24817$426a74cc@news.free.fr> NNTP-Posting-Host: 200.89.28.93.rev.sfr.net Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: cabale.usenet-fr.net 1670956683 20274 93.28.89.200 (13 Dec 2022 18:38:03 GMT) X-Complaints-To: abuse@usenet-fr.net NNTP-Posting-Date: Tue, 13 Dec 2022 18:38:03 +0000 (UTC) User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.1 In-Reply-To: <6398c186$0$24817$426a74cc@news.free.fr> Bytes: 6051 Bonjour Nicolas, et merci de ta réponse. Le 13/12/2022 à 19:16, Nicolas George a écrit : > >> 1er problème : lorsque le père fait un read() avec un paramètre count >> qui est plus grand que PIPE_BUF (c.-à-d. 4096), bien que le fils ait >> déjà écrit beaucoup plus d'octets que ça, seuls PIPE_BUF octets sont >> retournés par la commande read(). > > Ça c'est normal, et c'est même souhaitable, ça permet de faire du presque > bloquant qui marche. Personnellement je n'ai pas assez confiance que ce soit > portable, mais en théorie on peu compter dessus. Si tu veux lire une > certaine quantité, tu dois boucler. 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). >> 2e problème plus grave : lorsque le père fait un read() avec un count >> qui est plus *petit* que PIPE_BUF, ce sont bien seulement 'count' >> octets qui lui sont retournés, mais au total PIPE_BUF octets sont >> effacés du pipe ! Les (PIPE_BUF − count) octets restants sont perdus >> et ne seront jamais récupérés par le père lors des read() suivants. > > Là, je suis à peu près certain que tu hallucines. Tu peux montrer un strace > sur un exemple minimal ? 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. > 253 4956 write(8, "\x0d\x00\x00\x00\x02\x00\x00\x00\x50\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"..., 128) = 128 > 256 4955 read(7, "\x0d\x00\x00\x00\x02\x00\x00\x00\x50\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"..., 16376) = 128 > > 263 4955 write(6, "\x01\x00\x00\x00\x03\x00\x00\x00\xf8\x00\x00\x00\x00\x00\x00\x00\xa0\xd7\x23\x01\x00\x00\x00\x00\xff\x22\x40\x00\x00\x00\x00\x00"..., 248) = 248 > 265 4956 read(5, > 267 4956 <... read resumed>"\x01\x00\x00\x00\x03\x00\x00\x00\xf8\x00\x00\x00\x00\x00\x00\x00\xa0\xd7\x23\x01\x00\x00\x00\x00\xff\x22\x40\x00\x00\x00\x00\x00"..., 16376) = 248 > > 271 4956 write(8, "\x09\x00\x00\x00\x01\x00\x00\x00\xb8\xce\x0f\x00\x00\x00\x00\x00\xa0\xd7\x23\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"..., 4096) = 4096 > 278 4955 read(7, "\x09\x00\x00\x00\x01\x00\x00\x00\xb8\xce\x0f\x00\x00\x00\x00\x00\xa0\xd7\x23\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"..., 16376) = 4096 > > 272 4956 write(8, "\x01\x00\x00\x00\xa0\xc6\xee\x61\x02\x00\x00\x00\x04\x00\x00\x00\x34\x34\x2e\x30\x00\x00\x00\x00\x0c\x00\x00\x00\x02\x00\x00\x00"..., 4096) = 4096 > 287 4955 read(7, > 289 4955 <... read resumed>"\x01\x00\x00\x00\xa0\xc6\xee\x61\x02\x00\x00\x00\x04\x00\x00\x00\x34\x34\x2e\x30\x00\x00\x00\x00\x0c\x00\x00\x00\x02\x00\x00\x00"..., 12280) = 4096 > > 274 4956 write(8, "\x34\x34\x2e\x30\x00\x00\x00\x00\x0c\x00\x00\x00\x02\x00\x00\x00\x28\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\xc5\xde\xee\x61"..., 4096) = 4096 > 299 4955 read(7, > 301 4955 <... read resumed>"\x34\x34\x2e\x30\x00\x00\x00\x00\x0c\x00\x00\x00\x02\x00\x00\x00\x28\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\xc5\xde\xee\x61"..., 8184) = 4096 > > 276 4956 write(8, "\x28\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\xad\xf6\xee\x61\x02\x00\x00\x00\x04\x00\x00\x00\x34\x34\x2e\x30\x00\x00\x00\x00"..., 4096) = 4096 > 313 4955 read(7, > 315 4955 <... read resumed>"\x28\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\xad\xf6\xee\x61\x02\x00\x00\x00\x04\x00\x00\x00\x34\x34\x2e\x30\x00\x00\x00\x00"..., 4088) = 4088 > > 279 4956 write(8, "\x02\x00\x00\x00\x04\x00\x00\x00\x34\x33\x2e\x30\x00\x00\x00\x00\x0c\x00\x00\x00\x02\x00\x00\x00\x28\x00\x00\x00\x00\x00\x00\x00"..., 4096 > 282 4956 <... write resumed>) = 4096 > 332 4955 read(7, > 334 4955 <... read resumed>"\x02\x00\x00\x00\x04\x00\x00\x00\x34\x33\x2e\x30\x00\x00\x00\x00\x0c\x00\x00\x00\x02\x00\x00\x00\x28\x00\x00\x00\x00\x00\x00\x00"..., 16384) = 4096 -- Olivier Miakinen