-
Notifications
You must be signed in to change notification settings - Fork 584
rework tests for the PL_check change #17351
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
I was about to push a smoke-me branch for this, but decided to first test it locally. One test failure:
Thank you very much. |
Try this:
|
ef894f4
to
bf9eb61
Compare
@tonycoz I think these code changes have performance problems and are not ready for merging. I corrected the smoke-me branch I had created from your p.r. and proceeded to smoke it. On FreeBSD-11, running my most comprehensive configuration, the test suite as a whole aborted at the 9 hour max I have set in
Here is an example of the failure in
While it's not unusual to get failures during smoke-testing in (Because the run aborted, no report was generated, but I can gzip the log and send it to you if you want. See http://perl5.test-smoke.org/report/101038 for a more typical smoke-test run on this host with this configuration.) Granted, these failures could be due to transitory conditions on the host. But this needs more investigation before proceeding. Thank you very much. |
Yes please. The underlying change is pretty simple, I'd expect it to increase memory usage per interpreter by 3200 bytes, and start up time per interpreter is increased by copying that from the parent thread or the global version (which shouldn't be noticeable unless you're specifically benchmarking. At compile-time (for perl code, not the perl build itself) we're accessing an interpreter variable instead of a global, which shouldn't be any more expensive if my_perl (aTHX) ends up in a register. The tests should only have an effect on those tests, or any tests running in parallel with them, the new test in the first commit spawns 20 threads and tries to load XS::APItest in each thread, and that's moderately expensive, but my old Q6600 has no problem with it.
It might be useful to record the results of Recording |
[snip] This turned out to be the case. In the last week, instead of having only 1 or 2 virtual box VMs running on the host, I had 4. This sapped memory. For example, when I had 4 VMs running, I observed this line in
But when I shut down 3 of those 4 VMs, I observed this:
I then ran a new test of the branch I had created from Tony's p.r. using the same configuration. The result is here: smoke-report 101513. All tests PASS and the running time is actually slightly shorter than usual (though probably not to a statistically significant degree). Upshot: I no longer object to p.r. 17351. Thank you very much. |
Nicholas Clark's fix for IO makes the test in niner's patch meaningless, so test it separately.
io/handle.t depends on IO::Handle using the PL_check hack, but Nicholas's back portable fix no longer uses that Fix threaded perl detection, thanks to James Keenan.
bf9eb61
to
a8ba221
Compare
This failed on Win32 like in the Perl#17351 CI checks with: ../dist/if/t/if.t .................................................. ok Can't call method "sockdomain" on an undefined value at t/cachepropagate-tcp.t line 46. # Looks like your test exited with 9 just after 5. ../dist/IO/t/cachepropagate-tcp.t .................................. Dubious, test returned 9 (wstat 2304, 0x900) Failed 3/8 subtests I suspect what happened is there was a race between the parent accepting the connection and the child exiting and closing the connection. The Microsoft documentation for accept() indicates one possible reason for failure is: WSAECONNRESET An incoming connection was indicated, but was subsequently terminated by the remote peer prior to accepting the call. which I suspect happened here. So I've: - added a basic error check for the result of accept() - made the child to wait for the parent to close the socket - the parent explicitly closes the socket
This failed on Win32 like in the #17351 CI checks with: ../dist/if/t/if.t .................................................. ok Can't call method "sockdomain" on an undefined value at t/cachepropagate-tcp.t line 46. # Looks like your test exited with 9 just after 5. ../dist/IO/t/cachepropagate-tcp.t .................................. Dubious, test returned 9 (wstat 2304, 0x900) Failed 3/8 subtests I suspect what happened is there was a race between the parent accepting the connection and the child exiting and closing the connection. The Microsoft documentation for accept() indicates one possible reason for failure is: WSAECONNRESET An incoming connection was indicated, but was subsequently terminated by the remote peer prior to accepting the call. which I suspect happened here. So I've: - added a basic error check for the result of accept() - made the child to wait for the parent to close the socket - the parent explicitly closes the socket
This re-works #17240 while retaining the original commit and functional change.
Nicholas has an alternative fix that's more back-portable (currently in #17343), but he also says in Re-implement IO::Handle getline and getlines as XS code:
So this patch is still needed to fix the thread-safety issue.
If Nicholas's patch is applied the original
io/getlines.t
test is no longer meaningful, so I added similar code to XS::APItest, a test case for it and removed io/getlines.t.