Date: Thu, 6 Mar 2014 09:15:58 -0500 From: Eitan Adler <lists@eitanadler.com> To: Peter Holm <peter@holm.cc> Cc: "freebsd-testing@freebsd.org" <freebsd-testing@freebsd.org> Subject: Re: Test scenario for sysctl kern.maxfiles Message-ID: <CAF6rxgmDWg3G9td3sXFTouwG_nxc2cP8SjEy81gr1e_Md-HeGA@mail.gmail.com> In-Reply-To: <20140306112322.GA10664@x2.osted.lan> References: <20140305085806.GA70478@x2.osted.lan> <CAOtMX2hUJ2Hc62bG1jitbQbiHtb8b8Jm8iWaP4VaJPuADXR=Kw@mail.gmail.com> <20140306112322.GA10664@x2.osted.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6 March 2014 06:23, Peter Holm <peter@holm.cc> 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 <peter@holm.cc> 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. -- Eitan Adler
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAF6rxgmDWg3G9td3sXFTouwG_nxc2cP8SjEy81gr1e_Md-HeGA>