From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52794) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRQL8-0002qR-Qg for qemu-devel@nongnu.org; Tue, 31 May 2011 10:54:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QRQL5-0000Sk-0V for qemu-devel@nongnu.org; Tue, 31 May 2011 10:54:38 -0400 Message-ID: <4DE5011C.80000@siemens.com> Date: Tue, 31 May 2011 16:54:20 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1306705831-59385-1-git-send-email-andreas.faerber@web.de> <4DE4F16D.6030009@codemonkey.ws> <4DE4F5E2.5020906@siemens.com> <4DE4FAA1.7080109@codemonkey.ws> In-Reply-To: <4DE4FAA1.7080109@codemonkey.ws> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] Use SIGIO with caution List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "qemu-trivial@nongnu.org" , =?UTF-8?B?QW5kcmU=?= =?UTF-8?B?YXMgRsOkcmJlcg==?= , Marcelo Tosatti , "qemu-devel@nongnu.org" , Avi Kivity On 2011-05-31 16:26, Anthony Liguori wrote: > On 05/31/2011 09:06 AM, Jan Kiszka wrote: >> On 2011-05-31 15:47, Anthony Liguori wrote: >>> On 05/29/2011 04:50 PM, Andreas F=C3=A4rber wrote: >>>> BeOS and Haiku don't define SIGIO. When undefined, it won't arrive >>>> and doesn't need to be blocked. >>>> >>>> Signed-off-by: Andreas F=C3=A4rber >>> >>> Anything to do with signal masks is never a trivial patch BTW... >>> >>> But I actually think explicit handling of SIGIO is unneeded. I think >>> this is a hold over from the pre-I/O thread days where we selectively >>> set SIGIO on certain file descriptors to make sure that when an IO fd >>> became readable, we received a signal to break out of the KVM emulati= on >>> loop. >>> >>> Can the folks on CC confirm/deny? >>> >>> I can't see any use of SIGIO in the current source tree. >> >> At least qemu-timer.c uses SIGIO in HPET mode. That only applies to >> Linux hosts, though. >=20 > Is there any reason we still carry multiple timer implementations these= =20 > days? >=20 > HPET shouldn't be any better than dynticks. On any recent kernel, for sure. BTW, the same applies to the RTC timer. Jan --=20 Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux