[
https://issues.apache.org/jira/browse/STDCXX-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12573988#action_12573988
]
Travis Vitek commented on STDCXX-536:
-------------------------------------
We need to make some decisions here about how we want this to work. The options
that I see are
# If a test hits the hard timeout it fails. There is no soft timeout. This is
the current behavior.
# The number of iterations for blocks of each test will be reduced as needed to
execute before the hard timeout.
# Tests will be split into multiple tests, each with its own hard timeout. May
still require tweaking to iteration count.
# Tests will be split into multiple tests, each of which can have their own
soft timeout that would allow it to exit just before the hard timeout.
# The test itself will specify a block of code that is to be executed under the
soft timeout by invoking a function at the begin and end of that block. That
function will take a period and a callback function [similar to alarm()]
Any other ideas or comments?
> allow thread safety tests to time out without failing
> -----------------------------------------------------
>
> Key: STDCXX-536
> URL: https://issues.apache.org/jira/browse/STDCXX-536
> Project: C++ Standard Library
> Issue Type: Improvement
> Components: Tests
> Affects Versions: 4.2.0
> Reporter: Martin Sebor
> Assignee: Travis Vitek
> Fix For: 4.2.1
>
> Attachments: stdcxx-536.patch
>
>
> The newly added thread safety tests (and possibly some of the existing ones)
> tend to run for a long time, consuming a lot of CPU cycles, and sometimes
> even failing due to a timeout (currently 300 seconds in nightly builds). It
> would be useful to provide a mechanism such as a command line option whereby
> the tests' runtime could be limited without necessarily causing them to fail
> when the amount of time is exceeded. One way to do it would be for each test
> to set an alarm in response to this command line option and in handler for
> the alarm set a flag that each thread would check at each iteration of its
> loop to see if it should break.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
