From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LSIJp-0001Mx-0O for qemu-devel@nongnu.org; Wed, 28 Jan 2009 16:51:33 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LSIJm-0001M2-Ca for qemu-devel@nongnu.org; Wed, 28 Jan 2009 16:51:31 -0500 Received: from [199.232.76.173] (port=49456 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LSIJm-0001Lz-7R for qemu-devel@nongnu.org; Wed, 28 Jan 2009 16:51:30 -0500 Received: from soufre.accelance.net ([213.162.48.15]:49740) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LSIJl-0005HL-P8 for qemu-devel@nongnu.org; Wed, 28 Jan 2009 16:51:29 -0500 Received: from [192.168.0.3] (potipota.net [88.168.176.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by soufre.accelance.net (Postfix) with ESMTP id B71B545090 for ; Wed, 28 Jan 2009 22:51:27 +0100 (CET) Subject: Re: [Qemu-devel] [PATCH] flush stdout after printing usage() From: Lionel Landwerlin In-Reply-To: <20090128210639.GB4155@kos.to> References: <20090128184713.GA29581@kos.to> <4980BBC2.3050709@codemonkey.ws> <20090128210639.GB4155@kos.to> Content-Type: text/plain; charset=utf-8 Date: Wed, 28 Jan 2009 22:51:25 +0100 Message-Id: <1233179485.6716.7.camel@cocoduo.atr> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Le mercredi 28 janvier 2009 =C3=A0 23:06 +0200, Riku Voipio a =C3=A9crit = : > On Wed, Jan 28, 2009 at 02:10:42PM -0600, Anthony Liguori wrote: > > Riku Voipio wrote: > > >testcase: > > > > > >qemu-arm|grep cpu > > > > > >Without fflush() getting output from piped qemu is a bit random. >=20 > > It should get flushed upon exit(). Perhaps the problem is that we're=20 > > using _exit() instead of exit()? >=20 _exit does not trigger callbacks registred with at_exit. from the man page : The function _exit() is like exit(3), but does not call any func= tions registered with atexit(3) or on_exit(3). Whether it flushes sta= ndard I/O buffers and removes temporary files created with tmpfile(3= ) is implementation-dependent. On the other hand, _exit() does close= open file descriptors, and this may cause an unknown delay, waiting= for pending output to finish. If the delay is undesired, it may be u= seful to call functions like tcflush(3) before calling _exit(). Whether= any pending I/O is canceled, and which pending I/O may be canceled= upon _exit(), is implementation-dependent.