Test scenario for sysctl kern.maxfiles

[Alan Somers]

On Thu, Mar 6, 2014 at 9:29 AM, Peter Holm <peter at holm.cc> wrote:
> On Thu, Mar 06, 2014 at 07:44:58AM -0800, Garrett Cooper wrote:
>> 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
>>
>
> 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 at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-testing
> To unsubscribe, send any mail to "freebsd-testing-unsubscribe at freebsd.org"