site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=h8/w2AjUm+AfZ+jQL0Mp8D9lu1vVYnRXu53tOUc5fLD8+WvWMifN35gRZtVm3kjRrAiMH8iIIc6WAspp4CQ2qZUaiK+/VU5w+/sXoROIwgyoUuqyO48je48rtheVILqKK0xbmiuCYo92tNF1f57zLPMrNH0zjwBfKJZ7Ot+UQ/s= While I no longer rely on this behavior, I noticed a difference between 10.3 and 10.4 on the same fifo code. The 10.4 behavior seems more unfriendly than the 10.3 code, but I'm unsure which one is actually behaving "right". The code opens a fifo, then branches into 2 threads. One thread does some stuff, then calls close on the fifo. The other thread repeatedly reads from the fifo until some error occurs. All read/writes are blocking. The difference is what happens when the fifo is closed while the read is blocked. Under 10.3 the close() succeeds, but the read() remains blocked. The program can be terminated with a SIGTERM however. Under 10.4 the close() blocks, and the program requires a SIGKILL to, eventually, terminate. Example code is here: http://homepage.mac.com/funkmonkey256/FileSharing4.html The "close on blocked read example.zip". -- -Corey O'Connor _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com