From owner-freebsd-arch@FreeBSD.ORG Tue Jan 25 03:50:51 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1065916A4CE for ; Tue, 25 Jan 2005 03:50:51 +0000 (GMT) Received: from gizmo07bw.bigpond.com (gizmo07bw.bigpond.com [144.140.70.42]) by mx1.FreeBSD.org (Postfix) with SMTP id AD8CA43D53 for ; Tue, 25 Jan 2005 03:50:49 +0000 (GMT) (envelope-from andrew@areilly.bpc-users.org) Received: (qmail 24564 invoked from network); 25 Jan 2005 03:50:45 -0000 Received: from unknown (HELO bwmam03.bigpond.com) (144.135.24.75) by gizmo07bw.bigpond.com with SMTP; 25 Jan 2005 03:50:45 -0000 Received: from cpe-138-130-184-160.nsw.bigpond.net.au ([138.130.184.160]) by bwmam03.bigpond.com(MAM REL_3_4_2a 26/40368350) with SMTP id 40368350; Tue, 25 Jan 2005 13:50:45 +1000 Received: (qmail 28071 invoked by uid 1000); 25 Jan 2005 03:50:45 -0000 Date: Tue, 25 Jan 2005 14:50:45 +1100 From: Andrew Reilly To: Nicholas Ink Message-ID: <20050125035045.GA27895@gurney.reilly.home> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: FreeBSD Architecture Subject: Re: Continuation of the Mach Microkernel X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2005 03:50:51 -0000 On Fri, Jan 21, 2005 at 04:51:51PM -0500, Nicholas Ink wrote: > Has anyone tried running the Mach microkernel with a new version of > FreeBSD, like 5.x? I'm working on a project involving that > microkernel, but I'm concerned that it won't work with newer versions > of FreeBSD. > Does anyone know anything or know of any resources that might assist > me? How about the Darwin codebase? They recently upgraded their user-land to FreeBSD 5.something, I believe. -- Andrew From owner-freebsd-arch@FreeBSD.ORG Tue Jan 25 04:46:33 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D912516A4CE for ; Tue, 25 Jan 2005 04:46:33 +0000 (GMT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0D1E43D2D for ; Tue, 25 Jan 2005 04:46:33 +0000 (GMT) (envelope-from justin@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id j0P4kXcf011141 for ; Mon, 24 Jan 2005 20:46:33 -0800 (PST) Received: from [24.6.153.138] (c-24-6-153-138.client.comcast.net [24.6.153.138]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id j0P4kT8R018585 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 24 Jan 2005 20:46:32 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <20050125035045.GA27895@gurney.reilly.home> References: <20050125035045.GA27895@gurney.reilly.home> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1355BB97-6E8C-11D9-B0E6-00306544D642@mac.com> Content-Transfer-Encoding: 7bit From: Justin Walker Date: Mon, 24 Jan 2005 20:46:28 -0800 To: FreeBSD Architecture X-Mailer: Apple Mail (2.619) Subject: Re: Continuation of the Mach Microkernel X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2005 04:46:34 -0000 On Jan 24, 2005, at 19:50, Andrew Reilly wrote: > On Fri, Jan 21, 2005 at 04:51:51PM -0500, Nicholas Ink wrote: >> Has anyone tried running the Mach microkernel with a new version of >> FreeBSD, like 5.x? I'm working on a project involving that >> microkernel, but I'm concerned that it won't work with newer versions >> of FreeBSD. >> Does anyone know anything or know of any resources that might assist >> me? > > How about the Darwin codebase? They recently upgraded their > user-land to FreeBSD 5.something, I believe. Nope. The Darwin kernel uses some updates from FreeBSD 4.x, not 5.x. It isn't a wholesale import of FreeBSD, though. The device driver model is completely different, as is the interface between the network stacks and the devices. Also, just to be clear, Darwin doesn't use Mach as a microkernel. The implementation is more like Mach 2.x than Mac 3.x (even though the Mach bits are based on Mach 3.x): there is no support for running "guest OSs" in Darwin. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Some people have a mental | horizon of radius zero, and | call it their point of view. | -- David Hilbert *--------------------------------------*-------------------------------* From owner-freebsd-arch@FreeBSD.ORG Tue Jan 25 08:17:53 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EF9816A4CE for ; Tue, 25 Jan 2005 08:17:53 +0000 (GMT) Received: from gizmo08bw.bigpond.com (gizmo08bw.bigpond.com [144.140.70.18]) by mx1.FreeBSD.org (Postfix) with SMTP id 5C42343D46 for ; Tue, 25 Jan 2005 08:17:51 +0000 (GMT) (envelope-from andrew@areilly.bpc-users.org) Received: (qmail 29484 invoked from network); 25 Jan 2005 08:17:45 -0000 Received: from unknown (HELO bwmam03.bigpond.com) (144.135.24.75) by gizmo08bw.bigpond.com with SMTP; 25 Jan 2005 08:17:45 -0000 Received: from cpe-138-130-184-160.nsw.bigpond.net.au ([138.130.184.160]) by bwmam03.bigpond.com(MAM REL_3_4_2a 26/40679478) with SMTP id 40679478; Tue, 25 Jan 2005 18:17:45 +1000 Received: (qmail 31304 invoked by uid 1000); 25 Jan 2005 08:17:45 -0000 Date: Tue, 25 Jan 2005 19:17:45 +1100 From: Andrew Reilly To: Justin Walker Message-ID: <20050125081745.GA31139@gurney.reilly.home> References: <20050125035045.GA27895@gurney.reilly.home> <1355BB97-6E8C-11D9-B0E6-00306544D642@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1355BB97-6E8C-11D9-B0E6-00306544D642@mac.com> User-Agent: Mutt/1.4.2.1i cc: FreeBSD Architecture Subject: Re: Continuation of the Mach Microkernel X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2005 08:17:53 -0000 On Mon, Jan 24, 2005 at 08:46:28PM -0800, Justin Walker wrote: > > On Jan 24, 2005, at 19:50, Andrew Reilly wrote: > > >On Fri, Jan 21, 2005 at 04:51:51PM -0500, Nicholas Ink wrote: > >> Has anyone tried running the Mach microkernel with a new version of > >>FreeBSD, like 5.x? I'm working on a project involving that > >>microkernel, but I'm concerned that it won't work with newer versions > >>of FreeBSD. > >> Does anyone know anything or know of any resources that might assist > >>me? > > > >How about the Darwin codebase? They recently upgraded their > >user-land to FreeBSD 5.something, I believe. > > Nope. The Darwin kernel uses some updates from FreeBSD 4.x, not 5.x. I specified user-land, but the web pages on developer.apple.com indicate that synchronization-with and tracking of FreeBSD-stable is ongoing work. -stable now refers to 5.x, and I can't imagine them not wanting to incorporate some of the 5.x fine-grain locking work as it settles down. After all, there are plenty of multi-processor Mac boxes out there. > It isn't a wholesale import of FreeBSD, though. The device driver > model is completely different, as is the interface between the network > stacks and the devices. True. > Also, just to be clear, Darwin doesn't use Mach as a microkernel. The > implementation is more like Mach 2.x than Mac 3.x (even though the Mach > bits are based on Mach 3.x): there is no support for running "guest > OSs" in Darwin. I've often been puzzled why anyone using the Mach + BSD-single-server combination bothered with the "microkernel" moniker. Where's the win, there? Surely if you want a microkernel, then you look towards QNX, Hurd, Amoeba, L4 et al. Since FreeBSD was mentioned in the single-server context, I assumed that microkernel-ness wasn't important. I am interested in these issues, but haven't had the time or opportunity to investigate them myself, yet. Cheers, -- Andrew From owner-freebsd-arch@FreeBSD.ORG Tue Jan 25 09:11:11 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1701016A4CE for ; Tue, 25 Jan 2005 09:11:11 +0000 (GMT) Received: from mta10-winn.mailhost.ntl.com (smtpout18.mailhost.ntl.com [212.250.162.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id B44FF43D53 for ; Tue, 25 Jan 2005 09:11:09 +0000 (GMT) (envelope-from antony.t.curtis@ntlworld.com) Received: from aamta02-winn.mailhost.ntl.com ([212.250.162.8]) by mta10-winn.mailhost.ntl.com with ESMTP <20050125091108.PKHN20856.mta10-winn.mailhost.ntl.com@aamta02-winn.mailhost.ntl.com>; Tue, 25 Jan 2005 09:11:08 +0000 Received: from localhost.localdomain ([81.107.94.210]) by aamta02-winn.mailhost.ntl.com with ESMTP <20050125091108.NHJG3760.aamta02-winn.mailhost.ntl.com@localhost.localdomain>; Tue, 25 Jan 2005 09:11:08 +0000 From: Antony T Curtis To: Justin Walker In-Reply-To: <1355BB97-6E8C-11D9-B0E6-00306544D642@mac.com> References: <20050125035045.GA27895@gurney.reilly.home> <1355BB97-6E8C-11D9-B0E6-00306544D642@mac.com> Content-Type: text/plain Date: Tue, 25 Jan 2005 09:11:05 +0000 Message-Id: <1106644266.57883.3.camel@pcgem.rdg.cyberkinetica.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: FreeBSD Architecture Subject: Re: Continuation of the Mach Microkernel X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2005 09:11:11 -0000 On Mon, 2005-01-24 at 20:46 -0800, Justin Walker wrote: > On Jan 24, 2005, at 19:50, Andrew Reilly wrote: > > > On Fri, Jan 21, 2005 at 04:51:51PM -0500, Nicholas Ink wrote: > >> Has anyone tried running the Mach microkernel with a new version of > >> FreeBSD, like 5.x? I'm working on a project involving that > >> microkernel, but I'm concerned that it won't work with newer versions > >> of FreeBSD. > >> Does anyone know anything or know of any resources that might assist > >> me? > > > > How about the Darwin codebase? They recently upgraded their > > user-land to FreeBSD 5.something, I believe. > > Nope. The Darwin kernel uses some updates from FreeBSD 4.x, not 5.x. > It isn't a wholesale import of FreeBSD, though. The device driver > model is completely different, as is the interface between the network > stacks and the devices. > > Also, just to be clear, Darwin doesn't use Mach as a microkernel. The > implementation is more like Mach 2.x than Mac 3.x (even though the Mach > bits are based on Mach 3.x): there is no support for running "guest > OSs" in Darwin. There was a project someone had called something like MachBSD or xBSD which had a Mach microkernel and a FreeBSD 4.x userland - it had a project goal to reimplement FreeBSD but with a Mach-based kernel. The site disappeared sometime last year - it had a couple of ISOs but didn't have complete source online IIRC. -- Antony T Curtis, BSc. UNIX, Linux, *BSD, Networking antony.t.curtis@ntlworld.com C++, J2EE, Perl, MySQL, Apache IT Consultancy. From owner-freebsd-arch@FreeBSD.ORG Tue Jan 25 09:50:36 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02E4E16A4CE for ; Tue, 25 Jan 2005 09:50:36 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9ACA443D46 for ; Tue, 25 Jan 2005 09:50:35 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 7FEA5513D5; Tue, 25 Jan 2005 01:50:34 -0800 (PST) Date: Tue, 25 Jan 2005 01:50:34 -0800 From: Kris Kennaway To: Antony T Curtis Message-ID: <20050125095034.GA14180@xor.obsecurity.org> References: <20050125035045.GA27895@gurney.reilly.home> <1355BB97-6E8C-11D9-B0E6-00306544D642@mac.com> <1106644266.57883.3.camel@pcgem.rdg.cyberkinetica.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline In-Reply-To: <1106644266.57883.3.camel@pcgem.rdg.cyberkinetica.com> User-Agent: Mutt/1.4.2.1i cc: FreeBSD Architecture Subject: Re: Continuation of the Mach Microkernel X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2005 09:50:36 -0000 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 25, 2005 at 09:11:05AM +0000, Antony T Curtis wrote: > On Mon, 2005-01-24 at 20:46 -0800, Justin Walker wrote: > > On Jan 24, 2005, at 19:50, Andrew Reilly wrote: > >=20 > > > On Fri, Jan 21, 2005 at 04:51:51PM -0500, Nicholas Ink wrote: > > >> Has anyone tried running the Mach microkernel with a new version of > > >> FreeBSD, like 5.x? I'm working on a project involving that > > >> microkernel, but I'm concerned that it won't work with newer versions > > >> of FreeBSD. > > >> Does anyone know anything or know of any resources that might assist > > >> me? > > > > > > How about the Darwin codebase? They recently upgraded their > > > user-land to FreeBSD 5.something, I believe. > >=20 > > Nope. The Darwin kernel uses some updates from FreeBSD 4.x, not 5.x. = =20 > > It isn't a wholesale import of FreeBSD, though. The device driver=20 > > model is completely different, as is the interface between the network= =20 > > stacks and the devices. > >=20 > > Also, just to be clear, Darwin doesn't use Mach as a microkernel. The= =20 > > implementation is more like Mach 2.x than Mac 3.x (even though the Mach= =20 > > bits are based on Mach 3.x): there is no support for running "guest=20 > > OSs" in Darwin. >=20 > There was a project someone had called something like MachBSD or xBSD > which had a Mach microkernel and a FreeBSD 4.x userland - it had a > project goal to reimplement FreeBSD but with a Mach-based kernel. The > site disappeared sometime last year - it had a couple of ISOs but didn't > have complete source online IIRC. xmach? Run by jmallett@FreeBSD.org :-) Kris --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFB9hZqWry0BWjoQKURAvbnAJ9+8qguMA4bt6S7eKoGZ+1cRzFU9wCcD3QU mMKyOy182hIKSnFaHO6AuoE= =LoGS -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- From owner-freebsd-arch@FreeBSD.ORG Thu Jan 27 01:24:01 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A023516A4D0; Thu, 27 Jan 2005 01:24:01 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8966343D2D; Thu, 27 Jan 2005 01:24:01 +0000 (GMT) (envelope-from csjp@FreeBSD.org) Received: from freefall.freebsd.org (csjp@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j0R1O1Da053337; Thu, 27 Jan 2005 01:24:01 GMT (envelope-from csjp@freefall.freebsd.org) Received: (from csjp@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j0R1O1Co053336; Thu, 27 Jan 2005 01:24:01 GMT (envelope-from csjp) Date: Thu, 27 Jan 2005 01:24:01 +0000 From: "Christian S.J. Peron" To: arch@FreeBSD.org Message-ID: <20050127012401.GB48521@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: resolver un-conditionally restarts interrupted kevent X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2005 01:24:01 -0000 Hey I've noticed kind of an anoying feature with our resolver. It seems that if a process recieves a signal while waiting for a DNS response, kevent(2) will fail returning EINTR which sounds right. However I also noticed this: n = _kevent(kq, &kv, 1, &kv, 1, &ts); if (n < 0) { if (errno == EINTR) { (void) gettimeofday(&ctv, NULL); if (timercmp(&ctv, &timeout, <)) { timersub(&timeout, &ctv, &ctv); TIMEVAL_TO_TIMESPEC(&ctv, &ts); goto wait; Which un-conditionally restarts kevent(2) in the event of a signal. Logic tells me that the right way to do this would be to have the process set SA_RESTART when it registers a signal handler, and have kevent return ERESTART and IF kevent returns ERESTART, restart the signal. After further investigation into our multiplexing mechanisms like poll, select and kevent explicitly change ERESTART to EINTR. /* don't restart after signals... */ if (error == ERESTART) error = EINTR; else if (error == EWOULDBLOCK) error = 0; goto done; So I guess I have two questions 1) why do we explicitly change ERESTART to EINTR? 2) why do we unconditionally restart kevent in our resolver code? Any insight would be great, thanks! -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer From owner-freebsd-arch@FreeBSD.ORG Thu Jan 27 01:57:06 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A95416A4CE; Thu, 27 Jan 2005 01:57:06 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBEB143D1F; Thu, 27 Jan 2005 01:57:05 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j0R1v3GI055174; Thu, 27 Jan 2005 01:57:04 GMT (envelope-from davidxu@freebsd.org) Message-ID: <41F84C25.60903@freebsd.org> Date: Thu, 27 Jan 2005 10:04:21 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christian S.J. Peron" References: <20050127012401.GB48521@freefall.freebsd.org> In-Reply-To: <20050127012401.GB48521@freefall.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: resolver un-conditionally restarts interrupted kevent X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2005 01:57:06 -0000 Christian S.J. Peron wrote: > Hey > > I've noticed kind of an anoying feature with our resolver. It > seems that if a process recieves a signal while waiting for a > DNS response, kevent(2) will fail returning EINTR which sounds > right. However I also noticed this: > > n = _kevent(kq, &kv, 1, &kv, 1, &ts); > if (n < 0) { > if (errno == EINTR) { > (void) gettimeofday(&ctv, NULL); > if (timercmp(&ctv, &timeout, <)) { > timersub(&timeout, &ctv, &ctv); > TIMEVAL_TO_TIMESPEC(&ctv, &ts); > goto wait; > > Which un-conditionally restarts kevent(2) in the event of a signal. > Logic tells me that the right way to do this would be to have the > process set SA_RESTART when it registers a signal handler, and have > kevent return ERESTART and IF kevent returns ERESTART, restart the > signal. > > After further investigation into our multiplexing mechanisms like > poll, select and kevent explicitly change ERESTART to EINTR. > > /* don't restart after signals... */ > if (error == ERESTART) > error = EINTR; > else if (error == EWOULDBLOCK) > error = 0; > goto done; > > So I guess I have two questions > > 1) why do we explicitly change ERESTART to EINTR? Because they can not be simply restarted. those interfaces have in/out parameters which may already be changed by kernel before returning, also a timeout wait can not be restarted, you told kernel to sleep 10 minutes, and at minute 9, it gets a signal and is restarted, it will return to user code after totally 19 minutes. > 2) why do we unconditionally restart kevent in our > resolver code? > I think that's right because the code checks 'n < 0' first, it got nothing and does timeout calculation by itself, that's OK. > Any insight would be great, thanks! > From owner-freebsd-arch@FreeBSD.ORG Thu Jan 27 02:24:14 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE21216A4CE; Thu, 27 Jan 2005 02:24:14 +0000 (GMT) Received: from mx-mtaout02.mts.net (wnpgmb02-group-smtpout.mts.net [142.161.130.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9EC943D39; Thu, 27 Jan 2005 02:24:13 +0000 (GMT) (envelope-from modulus@wnpgmb11dc1-164-159.dynamic.mts.net) Received: from wnpgmb11dc1-164-159.dynamic.mts.net ([142.161.164.159]) by mx-mtaout02.mts.net with ESMTP <20050127022413.LAMX11399.mx-mtaout02.mts.net@wnpgmb11dc1-164-159.dynamic.mts.net>; Wed, 26 Jan 2005 20:24:13 -0600 Received: from wnpgmb11dc1-164-159.dynamic.mts.net (localhost [127.0.0.1]) j0R2Ox9Y066771; Wed, 26 Jan 2005 20:24:59 -0600 (CST) (envelope-from modulus@wnpgmb11dc1-164-159.dynamic.mts.net) Received: (from modulus@localhost)j0R2Ox2R066770; Wed, 26 Jan 2005 20:24:59 -0600 (CST) (envelope-from modulus) Date: Wed, 26 Jan 2005 20:24:59 -0600 From: "Christian S.J. Peron" To: David Xu Message-ID: <20050127022459.GA63961@wnpgmb11dc1-164-159.dynamic.mts.net> References: <20050127012401.GB48521@freefall.freebsd.org> <41F84C25.60903@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41F84C25.60903@freebsd.org> User-Agent: Mutt/1.4.2.1i cc: arch@freebsd.org Subject: Re: resolver un-conditionally restarts interrupted kevent X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2005 02:24:15 -0000 On Thu, Jan 27, 2005 at 10:04:21AM +0800, David Xu wrote: > Because they can not be simply restarted. those interfaces > have in/out parameters which may already be changed by kernel > before returning, also a timeout wait can not be restarted, you > told kernel to sleep 10 minutes, and at minute 9, it gets a signal > and is restarted, it will return to user code after totally 19 > minutes. Ok, that makes sense > > > 2) why do we unconditionally restart kevent in our > > resolver code? > > > I think that's right because the code checks 'n < 0' first, > it got nothing and does timeout calculation by itself, that's OK. The problem is this breaks many programs which use loops and conditions for program termination. Some examples are ping(8) and tcpdump(1). I.E. you go to ping some host or process some packets without -n and try to ctrl+c to interrupt the process, the program will not terminate because the resolver keeps restarting the kevent system call. Does anyone think it would make sense to not un-conditionally restart the system call and have EINTR (or something to this effect) propogate back to the process through h_errno? -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer From owner-freebsd-arch@FreeBSD.ORG Thu Jan 27 08:28:56 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41FAC16A4CE for ; Thu, 27 Jan 2005 08:28:56 +0000 (GMT) Received: from carmax.com (p6195-ipad51sasajima.aichi.ocn.ne.jp [60.38.198.195]) by mx1.FreeBSD.org (Postfix) with SMTP id 7738B43D41 for ; Thu, 27 Jan 2005 08:28:54 +0000 (GMT) (envelope-from nwzasdo@sol.dti.ne.jp) Date: Thu, 27 Jan 2005 06:57:16 +0000 From: Harrison Garrett To: Freebsd-arch References: In-Reply-To: Message-ID: <721J8B7H66CC452C@sol.dti.ne.jp> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Subject: software qtfldd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2005 08:28:56 -0000 new soft on http://mwxgtl.alfimbmkbd.info/?xg36zixAaBEWP11tieeaq Office 97 SR2 $40 MS Encarta Encyclopedia Delux 2004 (3CD) $80 MS Money 2004 $60 Office 2000 Premium Edition (2CD) $50 MS Project 2003 Professional $60 MS Plus! XP $50 Director MX 2004 $60 MS Streets and Trips 2004 $60 MS Plus! XP $50 MS Exchange 2003 Enterprise Server $60 FreeHand MX $60 PageMaker 7 (2CD) $60 Windows XP Professional With SP2 Full Version $70 LiveMotion 2.0 $60 MS SQL Server 2000 Enterprise Edition $60 Flash MX 2004 $60 MS Project 2003 Professional $60 Quark Xpress 6 Passport Multilanguage $60 MS Exchange 2003 Enterprise Server $60 Premiere 7 $60 MS Plus! XP $50 PageMaker 7 (2CD) $60 MS SQL Server 2000 Enterprise Edition $60 Premiere 7 $60 MS Exchange 2003 Enterprise Server $60 From owner-freebsd-arch@FreeBSD.ORG Thu Jan 27 16:07:35 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA5D816A4CE; Thu, 27 Jan 2005 16:07:35 +0000 (GMT) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39D8143D58; Thu, 27 Jan 2005 16:07:35 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])j0RG7XA6026882; Fri, 28 Jan 2005 03:07:33 +1100 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) j0RG7VVU028743; Fri, 28 Jan 2005 03:07:32 +1100 Date: Fri, 28 Jan 2005 03:07:31 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: "Christian S.J. Peron" In-Reply-To: <20050127022459.GA63961@wnpgmb11dc1-164-159.dynamic.mts.net> Message-ID: <20050128023756.E58087@delplex.bde.org> References: <20050127012401.GB48521@freefall.freebsd.org> <41F84C25.60903@freebsd.org> <20050127022459.GA63961@wnpgmb11dc1-164-159.dynamic.mts.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: David Xu Subject: Re: resolver un-conditionally restarts interrupted kevent X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2005 16:07:36 -0000 On Wed, 26 Jan 2005, Christian S.J. Peron wrote: > On Thu, Jan 27, 2005 at 10:04:21AM +0800, David Xu wrote: [On why the kernel changes ERESTART to EINTR for kevent() and a few other interfaces like poll()] > > Because they can not be simply restarted. those interfaces > > have in/out parameters which may already be changed by kernel > > before returning, also a timeout wait can not be restarted, you > > told kernel to sleep 10 minutes, and at minute 9, it gets a signal > > and is restarted, it will return to user code after totally 19 > > minutes. Perhaps a more fundamental reason is that not restarting is part of how these interfaces work. POSIX specifies it for poll() and select(). Changing signal handler[s] to restart automatically would be very bad even if it worked for kevent(). It would break applications that want other syscalls to not be restarted, and increase problems with applications longjmping out of signal handlers. > > > 2) why do we unconditionally restart kevent in our > > > resolver code? > > > > > I think that's right because the code checks 'n < 0' first, > > it got nothing and does timeout calculation by itself, that's OK. I think it is mostly historical -- applications or perhaps the library would not be prepared for __res_send() failing for any signal. > The problem is this breaks many programs which use loops and conditions > for program termination. Some examples are ping(8) and tcpdump(1). > > I.E. you go to ping some host or process some packets without -n and > try to ctrl+c to interrupt the process, the program will not terminate > because the resolver keeps restarting the kevent system call. This problem for ping was noticed soon after ping.c:status() was changed in rev.1.12 to just set a flag. It can't be easy to fix since it has lived for 8 years since then. Just setting flags in signal handlers is very hard to implement correctly. SA_RESTART must not be used for any signal handler, and EINTR must be handled for all syscalls and perhaps some library functions that would otherwise be restarted. ping attempts this but doesn't succeed because the resolver library doesn't cooperate. top's signal handling was broken by changing its signal handler[s] to just set a flag without even attempting this. So SIGINT doesn't kill top when top is blocked in read(). > Does anyone think it would make sense to not un-conditionally restart > the system call and have EINTR (or something to this effect) propogate > back to the process through h_errno? That is what should happen. I don't know if it is practical. Bruce From owner-freebsd-arch@FreeBSD.ORG Fri Jan 28 17:33:45 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C37816A4CE for ; Fri, 28 Jan 2005 17:33:45 +0000 (GMT) Received: from mx1.originative.co.uk (freebsd.gotadsl.co.uk [81.6.249.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1525A43D2F for ; Fri, 28 Jan 2005 17:33:45 +0000 (GMT) (envelope-from paul@mx1.originative.co.uk) Received: from localhost (unknown [127.0.0.1]) by mx1.originative.co.uk (Postfix) with ESMTP id B9D3615575 for ; Fri, 28 Jan 2005 17:33:43 +0000 (GMT) Received: from mx1.originative.co.uk ([127.0.0.1])port 10024) with ESMTP id 83633-06 for ; Fri, 28 Jan 2005 17:33:27 +0000 (GMT) Received: by mx1.originative.co.uk (Postfix, from userid 1000) id C8D8815579; Fri, 28 Jan 2005 17:33:27 +0000 (GMT) Date: Fri, 28 Jan 2005 17:33:27 +0000 From: Paul Richards To: arch@freebsd.org Message-ID: <20050128173327.GI61409@myrddin.originative.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: c99/c++ localised variable definition X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2005 17:33:45 -0000 This is likely to he highly contraversial, since generally change tends to be in this project. People used to programming in C++ or Perl (and many others) are used to defining variables as near to use as possible. This have never been possible before in C, but now with c99 it is. Personally, I find the c++/perl convention to be much less error prone and more intuitive and since c99 now supports it too it seems the standards body sees the benefits of this approach as well. So, are we going to start allowing this feature to be used in FreeBSD since it would require a pretty major change to style(9). I noticed when trying to use this feature that we're not running the compiler with c99 fully supported yet so I guess that's perhaps the first step to discuss. -- Paul Richards From owner-freebsd-arch@FreeBSD.ORG Fri Jan 28 18:36:25 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E60916A4CE for ; Fri, 28 Jan 2005 18:36:25 +0000 (GMT) Received: from mail18.syd.optusnet.com.au (mail18.syd.optusnet.com.au [211.29.132.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FC1843D31 for ; Fri, 28 Jan 2005 18:36:24 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j0SIaFL1022542 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 29 Jan 2005 05:36:20 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j0SIaE7l040529; Sat, 29 Jan 2005 05:36:14 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j0SIaBKI040528; Sat, 29 Jan 2005 05:36:11 +1100 (EST) (envelope-from pjeremy) Date: Sat, 29 Jan 2005 05:36:11 +1100 From: Peter Jeremy To: Paul Richards Message-ID: <20050128183611.GG32122@cirb503493.alcatel.com.au> References: <20050128173327.GI61409@myrddin.originative.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050128173327.GI61409@myrddin.originative.co.uk> User-Agent: Mutt/1.4.2i cc: arch@freebsd.org Subject: Re: c99/c++ localised variable definition X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2005 18:36:25 -0000 On Fri, 2005-Jan-28 17:33:27 +0000, Paul Richards wrote: >People used to programming in C++ or Perl (and many others) are used >to defining variables as near to use as possible. This have never been >possible before in C, but now with c99 it is. > >Personally, I find the c++/perl convention to be much less error prone >and more intuitive and since c99 now supports it too it seems the >standards body sees the benefits of this approach as well. It is most useful for variables with a short lexical lifetime in large functions. For a variable with a long lifetime - especially one which is infrequently referenced - it can make it much harder to locate the variable definition. It is also far less obvious what variable are in scope at any point - which is an issue if you are writing some new code and need a work variable. >So, are we going to start allowing this feature to be used in FreeBSD >since it would require a pretty major change to style(9). The biggest problem with making major changes to style(9) is that you wind up with two different styles intermixed in code. This tends to be far less readable than a single style. I would suggest that unless you can demonstrate a major advantage of the new style or intend to sweep the tree to update all existing code to match the new style (and this includes assisting developers with WIP) then you are unlikely to succeed. -- Peter Jeremy From owner-freebsd-arch@FreeBSD.ORG Fri Jan 28 18:44:04 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 189F916A4CE for ; Fri, 28 Jan 2005 18:44:04 +0000 (GMT) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB4AB43D1D for ; Fri, 28 Jan 2005 18:44:03 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 2F515148ED; Fri, 28 Jan 2005 12:44:01 -0600 (CST) Date: Fri, 28 Jan 2005 12:44:01 -0600 (CST) From: Mark Linimon X-X-Sender: linimon@pancho To: Paul Richards In-Reply-To: <20050128173327.GI61409@myrddin.originative.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: c99/c++ localised variable definition X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2005 18:44:04 -0000 On Fri, 28 Jan 2005, Paul Richards wrote: > This is likely to he highly controversial, since generally change > tends to be in this project. In my experience this usually depends on exactly how the changes are proposed, the track record of the proposer, and whether patches are supplied. mcl From owner-freebsd-arch@FreeBSD.ORG Fri Jan 28 18:49:26 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B04ED16A4ED for ; Fri, 28 Jan 2005 18:49:26 +0000 (GMT) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4605143D45 for ; Fri, 28 Jan 2005 18:49:26 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j0SInMce031709; Fri, 28 Jan 2005 13:49:23 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20050128173327.GI61409@myrddin.originative.co.uk> References: <20050128173327.GI61409@myrddin.originative.co.uk> Date: Fri, 28 Jan 2005 13:49:21 -0500 To: Paul Richards , arch@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) Subject: Re: c99/c++ localised variable definition X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2005 18:49:26 -0000 At 5:33 PM +0000 1/28/05, Paul Richards wrote: > >People used to programming in C++ or Perl (and many others) are >used to defining variables as near to use as possible. This has >never been possible before in C, but now with c99 it is. Well, you could get a similar effect by creating a new scope. >Personally, I find the c++/perl convention to be much less error >prone and more intuitive and since c99 now supports it too it seems >the standards body sees the benefits of this approach as well. > >So, are we going to start allowing this feature to be used in >FreeBSD since it would require a pretty major change to style(9). I used to do it that way (by creating new scopes and defining variables in there). The present style(9) caused me to abandon that practice, and in hindsight I think my routines are probably better off with all the variable-declarations grouped together. I don't feel too strongly about it, but I would slightly prefer that style(9) stay as it is on this. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Fri Jan 28 18:51:34 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55B0316A4CE for ; Fri, 28 Jan 2005 18:51:34 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC94943D41 for ; Fri, 28 Jan 2005 18:51:01 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [IPv6:::1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id j0SInJB1010409; Fri, 28 Jan 2005 11:49:20 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 28 Jan 2005 11:49:19 -0700 (MST) Message-Id: <20050128.114919.71097322.imp@bsdimp.com> To: paul@originative.co.uk From: Warner Losh In-Reply-To: <20050128173327.GI61409@myrddin.originative.co.uk> References: <20050128173327.GI61409@myrddin.originative.co.uk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@FreeBSD.ORG Subject: Re: c99/c++ localised variable definition X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2005 18:51:34 -0000 > So, are we going to start allowing this feature to be used in FreeBSD > since it would require a pretty major change to style(9). People differ as to the efficacy of such usage. Either they love it and can't understand why people wouldn't want to see definitions close to where they are used. Or they hate it and can't understand why you'd want to go searching for a definition when the one, true, god-given place is at the top of the function. Often times, no further discourse is possible because both sides know they are right, and the other side is a bunch of butt picking monekys that clearly should get out of the stone age... > I noticed when trying to use this feature that we're not running > the compiler with c99 fully supported yet so I guess that's perhaps > the first step to discuss. That's a reasonable thing to try to do, but it also opens up a number of side issues. We have already seen a taste of this in the WARNS=x efforts where people make it warns friendly to c99, only to discover that the system default is c89 and the fixes cause warnings/errors. Warner From owner-freebsd-arch@FreeBSD.ORG Fri Jan 28 19:58:38 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CAD416A4D0 for ; Fri, 28 Jan 2005 19:58:38 +0000 (GMT) Received: from Daffy.timing.com (daffy.timing.com [206.168.13.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77C5D43D46 for ; Fri, 28 Jan 2005 19:58:37 +0000 (GMT) (envelope-from ben@timing.com) Received: from piglet.timing.com (oink@piglet.timing.com [206.168.13.178]) by Daffy.timing.com (8.12.8p2/8.12.8) with ESMTP id j0SJwaEf091772; Fri, 28 Jan 2005 12:58:36 -0700 (MST) (envelope-from ben@timing.com) Received: from piglet.timing.com (oink@localhost.timing.com [127.0.0.1]) by piglet.timing.com (8.12.6p3/8.12.6) with ESMTP id j0SJwaOx050464; Fri, 28 Jan 2005 12:58:36 -0700 (MST) (envelope-from ben@piglet.timing.com) Received: (from ben@localhost) by piglet.timing.com (8.12.6p3/8.12.6/Submit) id j0SJwZpL050461; Fri, 28 Jan 2005 12:58:35 -0700 (MST) From: Ben Mesander MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16890.39275.761277.609543@piglet.timing.com> Date: Fri, 28 Jan 2005 12:58:35 -0700 To: Peter Jeremy In-Reply-To: <20050128183611.GG32122@cirb503493.alcatel.com.au> References: <20050128173327.GI61409@myrddin.originative.co.uk> <20050128183611.GG32122@cirb503493.alcatel.com.au> X-Mailer: VM 7.00 under Emacs 21.2.95.2 X-Virus-Scanned: ClamAV 0.80/664/Thu Jan 13 08:13:05 2005 clamav-milter version 0.80j on Daffy.timing.com X-Virus-Status: Clean cc: arch@freebsd.org cc: Paul Richards Subject: Re: c99/c++ localised variable definition X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2005 19:58:38 -0000 Peter Jeremy writes: > It is most useful for variables with a short lexical lifetime in large > functions. For a variable with a long lifetime - especially one which > is infrequently referenced - it can make it much harder to locate the > variable definition. It is also far less obvious what variable are > in scope at any point - which is an issue if you are writing some new > code and need a work variable. On the positive side, it is also very useful for allowing you to make things that shouldn't change really const. You can declare: const int foo = bar*GRONK + 37; in the middle of a block, and get a compile-time error if you try to change it later while maintaining the code. If you're forced to do all decl's at the top of a function, it's somewhat more work to be const correct. The other points you bring up are mostly big issues only if the functions in question are quite large, which some (but I'm not sure all) developers feel is indicative of other problems with the code. Regards, Ben From owner-freebsd-arch@FreeBSD.ORG Fri Jan 28 20:10:50 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CBD716A4CE for ; Fri, 28 Jan 2005 20:10:50 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id A996143D2F for ; Fri, 28 Jan 2005 20:10:49 +0000 (GMT) (envelope-from peadar.edwards@gmail.com) Received: by wproxy.gmail.com with SMTP id 58so482227wri for ; Fri, 28 Jan 2005 12:10:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=R/MZ3JHek6ka8EIJV8kKK3ARygXiTyMfN/1Sx+mJXE6H7/rsWtnjKmkykoYiF2MIVHobFIDsEFc49l5tSCGfhTboNWI14K96AyhgEBbQ/1b6HqEldZ5aMGYeW28/S07ZVuTmiPRGbI+xWvCBPYfwScJb5UNFDqO7VIyGRh+9lq0= Received: by 10.54.28.75 with SMTP id b75mr59164wrb; Fri, 28 Jan 2005 12:10:49 -0800 (PST) Received: by 10.54.57.76 with HTTP; Fri, 28 Jan 2005 12:10:49 -0800 (PST) Message-ID: <34cb7c84050128121077633d22@mail.gmail.com> Date: Fri, 28 Jan 2005 20:10:49 +0000 From: Peter Edwards To: Paul Richards In-Reply-To: <20050128173327.GI61409@myrddin.originative.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050128173327.GI61409@myrddin.originative.co.uk> cc: arch@freebsd.org Subject: Re: c99/c++ localised variable definition X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Peter Edwards List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2005 20:10:50 -0000 > Personally, I find the c++/perl convention to be much less error prone > and more intuitive and since c99 now supports it too it seems the > standards body sees the benefits of this approach as well. I also, personally, like using this particular feature when writing userland code. However, in terms of kernel stuff, there's a practical reason for grouping definitions of local variables together: you can have a much better idea of how much stack space you are using when introducing a new definition when all other definitions are nearby. i.e., although a pleasing feature in terms of writing clean code in algorithmically, it can be quite a danger when dealing with a very limited stack. From owner-freebsd-arch@FreeBSD.ORG Sat Jan 29 13:11:29 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39BB816A4CE for ; Sat, 29 Jan 2005 13:11:29 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id E52ED43D41 for ; Sat, 29 Jan 2005 13:11:28 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 7882E530C; Sat, 29 Jan 2005 14:11:27 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 335535308; Sat, 29 Jan 2005 14:11:03 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id B54CDB869; Sat, 29 Jan 2005 14:11:02 +0100 (CET) To: Paul Richards References: <20050128173327.GI61409@myrddin.originative.co.uk> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Sat, 29 Jan 2005 14:11:02 +0100 In-Reply-To: <20050128173327.GI61409@myrddin.originative.co.uk> (Paul Richards's message of "Fri, 28 Jan 2005 17:33:27 +0000") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on flood.des.no X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,FORGED_RCVD_HELO autolearn=disabled version=3.0.1 cc: arch@freebsd.org Subject: Re: c99/c++ localised variable definition X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2005 13:11:29 -0000 Paul Richards writes: > People used to programming in C++ or Perl (and many others) are used > to defining variables as near to use as possible. This have never been > possible before in C, but now with c99 it is. It's a very bad idea, because you can introduce new variables whenever you feel like, but you can't destroy them. Defining variables at the top of the scope forces you to think about which variables you need and how long they will live. Defining them on an ad hoc basis leads to sloppy programming and stack abuse. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Sat Jan 29 13:57:00 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61C6916A4CF for ; Sat, 29 Jan 2005 13:57:00 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 537E143D1D for ; Sat, 29 Jan 2005 13:56:59 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j0TDus5N045706; Sat, 29 Jan 2005 14:56:54 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 29 Jan 2005 14:11:02 +0100." Date: Sat, 29 Jan 2005 14:56:54 +0100 Message-ID: <45705.1107007014@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org cc: Paul Richards Subject: Re: c99/c++ localised variable definition X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2005 13:57:00 -0000 In message , =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= writes: >Paul Richards writes: >> People used to programming in C++ or Perl (and many others) are used >> to defining variables as near to use as possible. This have never been >> possible before in C, but now with c99 it is. > >It's a very bad idea, because you can introduce new variables whenever >you feel like, but you can't destroy them. Defining variables at the >top of the scope forces you to think about which variables you need >and how long they will live. Defining them on an ad hoc basis leads >to sloppy programming and stack abuse. Well... In ideal theory the compiler should reuse the stackspace but in practice we can't rely on it happening. I personally do like to be able to judge how much gunk a function puts on the stack by looking at the top of the function, rather than to have to hunt into umpteen levels for a "char buf[FAR_TOO_MUCH]". Far too many of the cases which define local scope variables in our current code base is bacause of lazy programmers who couldn't be bothered to locate an unused variable amongst the ones we already have and a minority is where the inner scope should really have been pulled into a separate function. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Sat Jan 29 14:00:48 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6784616A4CE; Sat, 29 Jan 2005 14:00:48 +0000 (GMT) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40E2343D3F; Sat, 29 Jan 2005 14:00:47 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.12.9p2/8.12.9) with ESMTP id j0TE0hnZ080636; Sat, 29 Jan 2005 17:00:43 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.12.9p2/8.12.9/Submit) id j0TE0dXF080630; Sat, 29 Jan 2005 17:00:39 +0300 (MSK) (envelope-from yar) Date: Sat, 29 Jan 2005 17:00:39 +0300 From: Yar Tikhiy To: Bruce Evans Message-ID: <20050129140038.GA71245@comp.chem.msu.su> References: <20050127012401.GB48521@freefall.freebsd.org> <41F84C25.60903@freebsd.org> <20050127022459.GA63961@wnpgmb11dc1-164-159.dynamic.mts.net> <20050128023756.E58087@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050128023756.E58087@delplex.bde.org> User-Agent: Mutt/1.5.6i cc: arch@freebsd.org cc: "Christian S.J. Peron" cc: David Xu Subject: Re: resolver un-conditionally restarts interrupted kevent X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2005 14:00:48 -0000 On Fri, Jan 28, 2005 at 03:07:31AM +1100, Bruce Evans wrote: > > Just setting flags in signal handlers is very hard to implement correctly. > SA_RESTART must not be used for any signal handler, and EINTR must be > handled for all syscalls and perhaps some library functions that would > otherwise be restarted. ping attempts this but doesn't succeed because > the resolver library doesn't cooperate. top's signal handling was > broken by changing its signal handler[s] to just set a flag without > even attempting this. So SIGINT doesn't kill top when top is blocked > in read(). BTW, even BSD stdio isn't friendly to signals w/o SA_RESTART. I ran into a rather nasty bug resulting in not less than data loss when a stdio call was interrupted and returned EINTR. I filed a PR on that, kern/76398, including a simple test program. It seems that programs using signals w/o SA_RESTART should block them for most of time and explicitly allow their delivery in carefully selected windows of safety. A significantly worse (but easier to implement) workaround could be to block such signals for the time spent in unsafe library calls. -- Yar From owner-freebsd-arch@FreeBSD.ORG Sat Jan 29 14:15:35 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1F5B16A4CE for ; Sat, 29 Jan 2005 14:15:35 +0000 (GMT) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57DFA43D53 for ; Sat, 29 Jan 2005 14:15:34 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.12.9p2/8.12.9) with ESMTP id j0TEFRnZ081168; Sat, 29 Jan 2005 17:15:27 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.12.9p2/8.12.9/Submit) id j0TEFQW8081167; Sat, 29 Jan 2005 17:15:26 +0300 (MSK) (envelope-from yar) Date: Sat, 29 Jan 2005 17:15:25 +0300 From: Yar Tikhiy To: Warner Losh Message-ID: <20050129141525.GB71245@comp.chem.msu.su> References: <20050128173327.GI61409@myrddin.originative.co.uk> <20050128.114919.71097322.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050128.114919.71097322.imp@bsdimp.com> User-Agent: Mutt/1.5.6i cc: arch@freebsd.org cc: paul@originative.co.uk Subject: Re: c99/c++ localised variable definition X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2005 14:15:35 -0000 On Fri, Jan 28, 2005 at 11:49:19AM -0700, Warner Losh wrote: > > So, are we going to start allowing this feature to be used in FreeBSD > > since it would require a pretty major change to style(9). > > People differ as to the efficacy of such usage. Either they love it > and can't understand why people wouldn't want to see definitions close > to where they are used. Or they hate it and can't understand why > you'd want to go searching for a definition when the one, true, > god-given place is at the top of the function. Often times, no > further discourse is possible because both sides know they are right, > and the other side is a bunch of butt picking monekys that clearly > should get out of the stone age... ...And which is even worse, the source code itself becomes a battleground for the two uncompromising sides. We have bloodstained src/ spots in plenty. Perhaps we need a law to stop the bloodshed, like it was in the Wild West? :-) It's becoming hard to find a scoped variable definition in some source files. And currently I cannot see a paragraph in style(9) on where local vars should be defined. Am I getting blind? -- Yar From owner-freebsd-arch@FreeBSD.ORG Sat Jan 29 18:05:28 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E56C16A4D9 for ; Sat, 29 Jan 2005 18:05:28 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAA2D43D46 for ; Sat, 29 Jan 2005 18:05:27 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 8AEDB46B20; Sat, 29 Jan 2005 13:05:27 -0500 (EST) Date: Sat, 29 Jan 2005 18:04:52 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Garance A Drosihn In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: Paul Richards Subject: Re: c99/c++ localised variable definition X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2005 18:05:28 -0000 On Fri, 28 Jan 2005, Garance A Drosihn wrote: > At 5:33 PM +0000 1/28/05, Paul Richards wrote: > > > >People used to programming in C++ or Perl (and many others) are > >used to defining variables as near to use as possible. This has > >never been possible before in C, but now with c99 it is. > > Well, you could get a similar effect by creating a new scope. And, FWIW, I've been hoping we could eliminate some use of "new scopes" in the current code, since they're typically used to hide the fact that excessive code is ifdef'd, or that a function should really be two functions. For example, you used to find a moderate amount (and still find some) in places like ip_input(), where people would arbitrarily add a block of code conditional on a semi-obscure kernel option, and then realize they needed variables and make it into a code block. Where it does occur, it's almost always a sign of a problem with the code structure. Here's the sort of thing I mean: int function(void) { /* lots of code */ #ifdef BASICALLY_UNUSED_BY_MOST_PEOPLE { struct foo *foo; int x; stuff(foo, x); } #endif One of the main situations in which I've found the declaration of variables close to their use helpful, as opposed to at the head of the function, is for temporary values relating to list or array iteration as part of a for loop. I.e., for (int i = 0; i < 100; i)) { } In this scenario, the re-use of i as part of a broader scope actually makes C warnings less useful, since you lose the benefit of stuff like "used but not initialized" warnings as the variables are reused. Maybe what we should be doing is identifying a couple of places where we are willing to take this approach, and it offers a clear benefit, and specifically pointing at those. I have to say that the type of coding style that annoys me somewhat to read in blended C/C++ code is this sort of thing: struct big foo; // ... large block of code struct another_big bar; // ... large block of code In environments with constrained stacks, especially in the kernel or threaded applications, having all the serious declarations up front makes it much easier to decide if things are getting out of hand. That's one reason why things like ancillary counter variables seem reasonable, but more extensive use can be problematic. Robert N M Watson From owner-freebsd-arch@FreeBSD.ORG Sat Jan 29 18:33:02 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1F1C16A4CE; Sat, 29 Jan 2005 18:33:02 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 613F643D3F; Sat, 29 Jan 2005 18:33:00 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.92] ([66.127.85.92]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j0TIWuWi037444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 29 Jan 2005 10:32:57 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <41FBD6F2.9050008@errno.com> Date: Sat, 29 Jan 2005 10:33:22 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: Garance A Drosihn cc: Paul Richards Subject: Re: c99/c++ localised variable definition X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2005 18:33:02 -0000 Robert Watson wrote: > On Fri, 28 Jan 2005, Garance A Drosihn wrote: > > >>At 5:33 PM +0000 1/28/05, Paul Richards wrote: >> >>>People used to programming in C++ or Perl (and many others) are >>>used to defining variables as near to use as possible. This has >>>never been possible before in C, but now with c99 it is. >> >>Well, you could get a similar effect by creating a new scope. > > > And, FWIW, I've been hoping we could eliminate some use of "new scopes" in > the current code, since they're typically used to hide the fact that > excessive code is ifdef'd, or that a function should really be two > functions. For example, you used to find a moderate amount (and still > find some) in places like ip_input(), where people would arbitrarily add a > block of code conditional on a semi-obscure kernel option, and then > realize they needed variables and make it into a code block. Where it > does occur, it's almost always a sign of a problem with the code > structure. Here's the sort of thing I mean: > > int > function(void) > { > > /* lots of code */ > > #ifdef BASICALLY_UNUSED_BY_MOST_PEOPLE > { > struct foo *foo; > int x; > > stuff(foo, x); > } > #endif When variables are used only in a limited scope I find it better to locate it close to the code rather than some far off spot like the outermost block. Your example above could easily be a case like that. Forcing variable declarations to the top of the function means extra #ifdef's and makes it easy to forget if you happen to delete or alter the code body. > > One of the main situations in which I've found the declaration of > variables close to their use helpful, as opposed to at the head of the > function, is for temporary values relating to list or array iteration as > part of a for loop. I.e., > > for (int i = 0; i < 100; i)) { > > } > > In this scenario, the re-use of i as part of a broader scope actually > makes C warnings less useful, since you lose the benefit of stuff like > "used but not initialized" warnings as the variables are reused. Maybe > what we should be doing is identifying a couple of places where we are > willing to take this approach, and it offers a clear benefit, and > specifically pointing at those. I have to say that the type of coding > style that annoys me somewhat to read in blended C/C++ code is this sort > of thing: > > struct big foo; > > // ... large block of code > > struct another_big bar; > > // ... large block of code > > In environments with constrained stacks, especially in the kernel or > threaded applications, having all the serious declarations up front makes > it much easier to decide if things are getting out of hand. That's one > reason why things like ancillary counter variables seem reasonable, but > more extensive use can be problematic. One thing I especially like about c++'s ability to declare variables mid-block in that it lets you insure variables are initialized by combining declaration and initialization. That is instead of int needed_somewhere_way_far_away; ...lots of code... needed_somewhere_way_far_away = something_not_available_at_top_of_function; you can combine the decl and the initialization. This is a requirement when you want to use const. Sam