From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9613 invoked by alias); 29 Apr 2010 13:29:23 -0000 Received: (qmail 9603 invoked by uid 22791); 29 Apr 2010 13:29:23 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from ns2.sietec.de (HELO mail.sietec.de) (213.61.69.205) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 29 Apr 2010 13:29:17 +0000 Received: from mail.bln1.bf.nsn-intra.net (ns2.bln1.bf.nsn-intra.net [10.149.159.159]) by mail.sietec.de (8.13.5/8.13.5/MTA) with ESMTP id o3TDTDdc012918 for ; Thu, 29 Apr 2010 15:29:14 +0200 (MEST) Received: from [10.149.155.84] (stbm8186.bln1.bf.nsn-intra.net [10.149.155.84]) by mail.bln1.bf.nsn-intra.net (8.13.5/8.13.5/MTA) with ESMTP id o3TDTDXm020157 for ; Thu, 29 Apr 2010 15:29:13 +0200 (CEST) Message-ID: <4BD989A9.4080402@towo.net> Date: Thu, 29 Apr 2010 14:18:00 -0000 From: Thomas Wolff User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: select() hanging after terminal killed References: <201004291053.o3TAr15g018361@mail.bln1.bf.nsn-intra.net> <4BD96D59.7080808@gmx.de> In-Reply-To: <4BD96D59.7080808@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2010-04/txt/msg01019.txt.bz2 On 29.04.2010 13:28, Matthias Andree wrote: > Am 29.04.2010 12:53, schrieb Thomas Wolff: > > [on closed terminal] > >> On Linux, select() indicates an exception and EIO. >> On SunOS, select() indicates both an exception and input (weird), >> > Not weird, you appear to be misunderstanding select(). > An IEEE Std 1003.1 compliant select(): > > - only states that a subsequent read() will *not block* > this includes EOF and error, as they make read() return without blocking) > > - makes *no statements about success* > Oh, right, so apparently Linux is wrong here (since it does not report read availability...). >> On Cygwin, the following is observed: >> * EOF is not signalled on read(); rather EIO is indicated right away. >> (Maybe not too bad, an application can handle that as well.) >> * select() with timeout hangs. >> >> Especially the latter can hardly be handled by an application. >> > Pointers for workarounds: alarm(), signal(). > So I could setup alarm() to get myself signal()ed while waiting in a long sleep(). But the granularity is in seconds only, so this is not a substitute for most use cases typically handled by calling select(). Thanks for the information anyway. ------ Thomas -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple