This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Thu, Nov 06, 2014 at 08:52:16AM +0100, Leonhard Holz wrote: > Well, the former implementation just relied on running into timeout because > of swapping and collating time, but it could not guarantee it. With enough > hardware resources (maybe 10GB memory and a high end cpu) the test would > have completeted within the five minutes boundary - and then counted as > failed. This test should have succeeded on alarm as well as normal completion, but may not be the case for a lot of EXPECTED_SIGNAL tests where a normal completion is a failure and the test may not have handled it correctly, i.e. returning non-zero finally. If you can prove that all tests that use EXPECTED_SIGNAL handle completion correctly then your patch may be acceptable. > Now the needed hardware resources to complete in time have been lowered a > lot but the overall behaviour has not changed: If the test machine is > capable enough the test does complete, if not it runs into timeout (there is > still an allocation of 1GB). Because of this I decided to fix the test > implementation to support both outcomes. If this feels to luxurious I'd vote > for setting the timeout much lower (30s?) so that the test suite completes > faster. Set the timeout to a value that is large enough to allow the test to complete without an alarm on commodity hardware. If someone finds that it is not large enough they can always patch it to increase it. Siddhesh
Attachment:
pgp32ggrR3VNp.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |