From owner-freebsd-testing@FreeBSD.ORG Thu Mar 6 15:44:59 2014 Return-Path: Delivered-To: freebsd-testing@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D5F8C42C for ; Thu, 6 Mar 2014 15:44:59 +0000 (UTC) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A845D604 for ; Thu, 6 Mar 2014 15:44:59 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id fa1so2833017pad.0 for ; Thu, 06 Mar 2014 07:44:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=I5TG+SSSeJ8BIGcRO3Cffm352VSLmtQE7FEEdw0Xe5s=; b=dFfBUDG6qZYntCM5xGrY1ch4QtTakCFBBbybzr3t8U5XZ4D1rI6u01Y3GUEi+xghfE pYh7vuzHiUkCtfjYbJUQR/dnCbTZ5n1zrvcPAurbYWFC1PDxIFgWZvpOUzkhs8zlDNOb emcEV/dqssHIq5NQJN8gVnVdCaljp9GI4UYd5ma6AnbIkPofw0Gj+CwDQKIChd+omMbw mKnXxYGpujiVxYet8DOndzJ3wL4OvMFwaTlVLLP5IP5066S3AAX9CDOVnePlW9MDDBVS ufNeVjs6MBvvGastFnJpN8YVFdT6/Jfbw6VchxOESOalRzj0EusCBEerjCxp+tWMD1B/ l3dA== X-Received: by 10.66.121.231 with SMTP id ln7mr15301249pab.33.1394120699270; Thu, 06 Mar 2014 07:44:59 -0800 (PST) Received: from [192.168.20.5] (c-24-17-226-153.hsd1.wa.comcast.net. [24.17.226.153]) by mx.google.com with ESMTPSA id bc4sm21077754pbb.2.2014.03.06.07.44.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 07:44:57 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Test scenario for sysctl kern.maxfiles From: Garrett Cooper In-Reply-To: <20140306153247.GA22830@x2.osted.lan> Date: Thu, 6 Mar 2014 07:44:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6A23D2B5-4EAA-46EF-A582-8C55FE0ED46B@gmail.com> References: <20140305085806.GA70478@x2.osted.lan> <20140306112322.GA10664@x2.osted.lan> <20140306153247.GA22830@x2.osted.lan> To: Peter Holm X-Mailer: Apple Mail (2.1874) Cc: "freebsd-testing@freebsd.org" X-BeenThere: freebsd-testing@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Testing on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 15:45:00 -0000 On Mar 6, 2014, at 7:32 AM, Peter Holm wrote: > On Thu, Mar 06, 2014 at 09:15:58AM -0500, Eitan Adler wrote: >> On 6 March 2014 06:23, Peter Holm wrote: >>> On Wed, Mar 05, 2014 at 10:08:49AM -0700, Alan Somers wrote: >>>> On Wed, Mar 5, 2014 at 1:58 AM, Peter Holm wrote: >>>>> Here's an attempt to verify that increasing kern.maxfiles works as >>>>> expected. >>>>>=20 >>>>> http://people.freebsd.org/~pho/kern_descrip_test-v3.diff >>>>> -- >>>>> Peter >>>>=20 >>>> 1) done should be of type "static volatile sig_atomic_t", not int, >>>> because it's set by signal handlers. >>>>=20 >>>=20 >>> Yes, that is nicer (I learned something new today :-). But the use >>> here works because there is a call to usleep(3) after each test, >>> forcing the compiler to reload the "done" variable. >>=20 >> That isn't what sig_atomic_t is trying to prevent. It is an = ""integer >> type of an object that can be accessed as an atomic entity, even in >> the presence of asynchronous interrupts."". In particular, on some >> machines it would be possible for the signal handler to observe a >> half-updated "int" type variable. >>=20 >> On i386 sig_atomic_t happens to be an "int". On amd64 it happens to >> be a long. This is not contractual. >>=20 >=20 > I only just realize that the ATF test programs are threaded. > Anyway it seems to be a good practice to always use "static volatile > sig_atomic_t" for signal handler variables. ATF forks, doesn=92t spawns threads: # grep -r pthread contrib/atf/ || echo not threaded not threaded I think that the point that others were trying to make here is that it = sets a good standard/precedence to program with atomicity in mind = instead of it not being involved, because of how signal handlers are = designed. Cheers, -Garrett=