From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6116 invoked by alias); 29 Apr 2010 15:59:38 -0000 Received: (qmail 6105 invoked by uid 22791); 29 Apr 2010 15:59:37 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from mail.gmx.net (HELO mail.gmx.net) (213.165.64.20) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Thu, 29 Apr 2010 15:59:31 +0000 Received: (qmail invoked by alias); 29 Apr 2010 15:59:29 -0000 Received: from baloo.cs.uni-paderborn.de (EHLO baloo.cs.uni-paderborn.de) [131.234.21.116] by mail.gmx.net (mp056) with SMTP; 29 Apr 2010 17:59:29 +0200 Received: from [127.0.0.1] (helo=balu.cs.uni-paderborn.de) by baloo.cs.uni-paderborn.de with esmtp (Exim 4.70) (envelope-from ) id L1NB33-0001D4-AC for cygwin@cygwin.com; Thu, 29 Apr 2010 17:59:27 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: cygwin@cygwin.com Subject: Re: select() hanging after terminal killed References: <201004291053.o3TAr15g018361@mail.bln1.bf.nsn-intra.net> <4BD96D59.7080808@gmx.de> <4BD989A9.4080402@towo.net> Date: Thu, 29 Apr 2010 16:40:00 -0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Matthias Andree" Message-ID: In-Reply-To: <4BD989A9.4080402@towo.net> User-Agent: Opera Mail/10.52 (Win32) 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/msg01028.txt.bz2 Thomas Wolff wrote on 2010-04-29: > 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...). Arguably yes, probably an omission in your system. (Note that older POSIX versions didn't specify that errors means readability). Please look if a relevant bug is filed, and if not, please do so. >>> 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. Rather than discussing the downsides, you might more efficiently just read the standard, or the system documentation, which would then point you to setitimer(). -- Matthias Andree -- 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