From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KxjsJ-00040T-Di for qemu-devel@nongnu.org; Wed, 05 Nov 2008 10:00:51 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KxjsI-0003z6-41 for qemu-devel@nongnu.org; Wed, 05 Nov 2008 10:00:50 -0500 Received: from [199.232.76.173] (port=44225 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KxjsH-0003yd-Uz for qemu-devel@nongnu.org; Wed, 05 Nov 2008 10:00:49 -0500 Received: from mail2.shareable.org ([80.68.89.115]:42941) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KxjsH-00015Q-Bw for qemu-devel@nongnu.org; Wed, 05 Nov 2008 10:00:49 -0500 Date: Wed, 5 Nov 2008 15:00:42 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] Re: [5578] Increase default IO timeout from 10ms to 5s Message-ID: <20081105150042.GJ13630@shareable.org> References: <49100654.6020108@web.de> <20081104113204.GA32125@shareable.org> <20081104.092231.-1384053398.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081104.092231.-1384053398.imp@bsdimp.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "M. Warner Losh" Cc: jan.kiszka@web.de, qemu-devel@nongnu.org M. Warner Losh wrote: > : In other words, don't use pselect() if you might run on a kernel older > : than 2.6.16, or on a host architecture which adds pselect() in a later > : kernel version. Also, I wouldn't be surprised if older versions of > : some BSDs have similar dodgy wrappers. > > Which ones have a good kernel implementation of it? FreeBSD's is > currently approximately: > > if (!mask) > _sigprocmask(mask, &oldmask); > /* here */ > select(); > if (!mask) > _sigprocmask(oldmask, NULL); > > I'm assuming that the problem is due to a signal arriving at /* here */. If that's _kernel_ code and the kernel behaves like Linux, it's not a problem because signals don't affect the control flow until returning to userspace, meaning the select() will return EINTR. If that's userspace (libc) code, then it is no good. Nobody should ever have written crappy pselect() wrappers in userspace (i.e. Glibc), it just causes portable software to have to keep a whitelist of reliable pselect() platforms (i.e. not Linux) instead of just using it. Same for crappy broken pread() and pwrite() wrappers. -- Jamie