stdcxx-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Sebor (JIRA)" <j...@apache.org>
Subject [jira] Commented: (STDCXX-536) allow thread safety tests to time out without failing
Date Thu, 08 May 2008 04:04:55 GMT

    [ 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.


Mime
View raw message