From owner-freebsd-testing@FreeBSD.ORG Thu Mar 6 17:41:25 2014 Return-Path: Delivered-To: freebsd-testing@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1E35E5EE for ; Thu, 6 Mar 2014 17:41:25 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A88E3252 for ; Thu, 6 Mar 2014 17:41:24 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id z12so3594292wgg.17 for ; Thu, 06 Mar 2014 09:41:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=t3XYcbR/chFhOYDNPDIVyUKoyrquXCLQbJHONiKBHOE=; b=eaumJbQPycEKRHKB4zydZ4BWBAURnaQ0vnlwcRLWLfiBo36PJ2h1fUtyYULkGL5hu5 0pXALHLq/xXnti2ifRMzVOVdB5U+c7WTZtJQ2hZG60M/MvjA/xQHl/0rVDTTLiVpPcb7 3zCIKXwqBjqh9nuPcdOs/EfxK26ifY4OTSWLwzQZ9Lat71yBenaETbzXgnMmVwA764p2 EqsqA3DgoRtWdnwzBcb50NnRGhQH/idR2J3NgVsmK/ol3eh17QXXzemBuVmHZ//gstZm A62xY22R3m+JHyNCFoIo1dKzgvznUafRbxqbZK0ugB3LIUPBTJ4rGpSMYsKo5A7V0Z45 NWUQ== MIME-Version: 1.0 X-Received: by 10.194.57.239 with SMTP id l15mr12399049wjq.40.1394127670120; Thu, 06 Mar 2014 09:41:10 -0800 (PST) Sender: asomers@gmail.com Received: by 10.194.168.197 with HTTP; Thu, 6 Mar 2014 09:41:10 -0800 (PST) In-Reply-To: <20140306162934.GB25614@x2.osted.lan> References: <20140305085806.GA70478@x2.osted.lan> <20140306112322.GA10664@x2.osted.lan> <20140306153247.GA22830@x2.osted.lan> <6A23D2B5-4EAA-46EF-A582-8C55FE0ED46B@gmail.com> <20140306162934.GB25614@x2.osted.lan> Date: Thu, 6 Mar 2014 10:41:10 -0700 X-Google-Sender-Auth: wT0WkvYch1DmctqfoTWwBCcpFR4 Message-ID: Subject: Re: Test scenario for sysctl kern.maxfiles From: Alan Somers To: Peter Holm Content-Type: text/plain; charset=ISO-8859-1 Cc: Garrett Cooper , "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 17:41:25 -0000 On Thu, Mar 6, 2014 at 9:29 AM, Peter Holm wrote: > On Thu, Mar 06, 2014 at 07:44:58AM -0800, Garrett Cooper wrote: >> 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. >> >>>>> >> >>>>> http://people.freebsd.org/~pho/kern_descrip_test-v3.diff >> >>>>> -- >> >>>>> Peter >> >>>> >> >>>> 1) done should be of type "static volatile sig_atomic_t", not int, >> >>>> because it's set by signal handlers. >> >>>> >> >>> >> >>> 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. >> >> >> >> 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. >> >> >> >> On i386 sig_atomic_t happens to be an "int". On amd64 it happens to >> >> be a long. This is not contractual. >> >> >> > >> > 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?t spawns threads: >> >> # grep -r pthread contrib/atf/ || echo not threaded >> not threaded >> > > Hmm ... OK. > > $ ldd /usr/tests/sys/kern/unix_seqpacket_test > /usr/tests/sys/kern/unix_seqpacket_test: > libthr.so.3 => /lib/libthr.so.3 (0x2806f000) > libatf-c.so.1 => /usr/lib/libatf-c.so.1 (0x28091000) > libc.so.7 => /lib/libc.so.7 (0x280a5000) > $ That's my fault. Some of the test cases themselves require threads; not the ATF framework. I could've used fork() for those test cases, but in this case using threads was easier so they could share address space. > >> 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. >> > > Oh, I absolutely agree. > -- > Peter > _______________________________________________ > freebsd-testing@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-testing > To unsubscribe, send any mail to "freebsd-testing-unsubscribe@freebsd.org"