site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com User-agent: Mozilla Thunderbird 1.0 (Windows/20041206) anybody knows about a bug on the select on the close detection on a pipe ?? thanks hervé begin:vcard fn;quoted-printable:Herv=C3=A9 Kergourlay n;quoted-printable:Kergourlay;Herv=C3=A9 org:Atempo;Engineering email;internet:herve.kergourlay@atempo.com title:Vos group Manager tel;work:02 97 68 40 29 tel;fax:02 97 68 40 25 tel;home:02 97 42 41 76 note:Only those who attempt the absurd can achieve the impossible x-mozilla-html:TRUE url:http://www.atempo.com version:2.1 end:vcard _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com on a clent/server schema with 2 processes, one, the producer is writing on a pipe, the other read the pipe with recv in an asynchronous mode so it's calling select() until the data are really available then is calling recv(). Everything is ok if the producer send datas. But the select() API on a pipe handle stays blocked until the timeout ends if the write process close the socket before sending all the datas if I'm using a socket instead of a pipe, the close is detected and the select return If I'm calling a blocking recv directly, the close is also detected This code is a unix standard code which is working on all standard Unix (linux, sun, hp, sgi, etc ...)