[
https://issues.apache.org/jira/browse/STDCXX-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595114#action_12595114
]
Martin Sebor commented on STDCXX-536:
-------------------------------------
One request: can you separate out changes that are unrelated to the timeout
enhancement to make this patch easier to review?
Other than that, a few questions/concerns:
# Is
[{{alarm()}}|http://www.opengroup.org/onlinepubs/009695399/functions/alarm.html]
safe to use with multiple threads? Would having the main thread sleep until
the timeout expires and then set the flag be a safer and simpler approach?
# Should the same timeout mechanism as in {{rw_thread_pool()}} be also used in
{{rw_thread_create()}}?
# Is the overhead of calling a function in each iteration of the thread loop to
check the timeout flag significant enough to consider exposing the flag itself?
(E.g., as a {{const volatile sig_atomic_t &rw_thread_timeout}} initialized to
refer to the actual, non-{{const}} flag, to prevent thread functions from
modifying it while allowing the the driver to (indirectly) set it.)
> 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.2
>
> Attachments: stdcxx-536.patch
>
> Original Estimate: 3h
> Time Spent: 4h
> Remaining Estimate: 0h
>
> 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.
