TestCLI#test_control failing with "pool_capacity": 0

[junaruga]

Describe the bug

A clear and concise description of what the bug is.

TestCLI#test_control (test/test_cli.rb:175)sometimes fails with the result "pool_capacity": 0 with following message.
Do you have any idea to pass the test such as injecting sleeping time before the assertion, and etc?

  5) Failure:
TestCLI#test_control [/builddir/build/BUILD/puma-4.3.3/usr/share/gems/gems/puma-4.3.3/test/test_cli.rb:175]:
Expected /{ "started_at": "\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}Z", "backlog": 0, "running": 0, "pool_capacity": 16, "max_threads": 16 }/ to match # encoding: ASCII-8BIT
#    valid: true
"{ \"started_at\": \"2020-03-30T18:59:23Z\", \"backlog\": 0, \"running\": 0, \"pool_capacity\": 0, \"max_threads\": 16 }".

Puma config:

Please copy-paste your Puma config AND your command line options here.

It's not the target.

To Reproduce

Please add reproduction steps here.

This issue sometimes happened for CPU architectures ppc64le or s390x on Fedora project's build system. Note this system does not provide the internet to outside in it. But the loop back network is available.

Your issue will be solved very quickly if you can reproduce it with a "hello world" rack application. To do this, copy this into a file called hello.ru:

I can not reproduce it with the "hello world" rack application.

There is also a Dockerfile available for reproducing Linux-specific issues. To use:

I have a willing to work for that, if you need it. Maybe I will try to reproduce it with Travis multple CPU feature arch: ppc64le and arch: s390x.

Expected behavior

A clear and concise description of what you expected to happen.

TestCLI#test_control passes.

Desktop (please complete the following information):

• OS: Fedora 33 (= rawhide = development version) Linux
• Puma Version: 4.3.3
• Ruby Version: 2.7.0

[wjordan]

A thread-context switch can happen exactly after @launcher.events.fire_on_booted! and before server.run creating the thread pool in Puma::Single:

puma/lib/puma/single.rb

Lines 57 to 63 in f47d6d1

	@launcher.events.fire_on_booted!
	begin
	server.run.join
	rescue Interrupt
	# Swallow it
	end

Adding a sleep 0.1 on line 58 triggers the bug reliably for me.

[nateberkopec]

Wanted: a custom mutation tester that adds sleep 0.1 to every line under test 😆