Test scenario for sysctl kern.maxfiles

[Garrett Cooper]

On Mar 6, 2014, at 7:32 AM, Peter Holm <peter at holm.cc> wrote:

> On Thu, Mar 06, 2014 at 09:15:58AM -0500, Eitan Adler wrote:
>> On 6 March 2014 06:23, Peter Holm <peter at 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 at 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.
>> 
> 
> 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

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