[
https://issues.apache.org/jira/browse/STDCXX-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595470#action_12595470
]
Martin Sebor commented on STDCXX-536:
-------------------------------------
I was hoping there would be a way to wake up the sleeping thread when the
threads were done but it doesn't look like Pthreads has a feature like that
({{pthreads_timed_join()}}?) I'm just a little nervous about the interactions
between signals and threads (POSIX [Signal
Concepts|http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html]
describes some of the intricacies). And then I guess the purist in me would
prefer a pthreads-only solution if there is one. I wonder if we could emulate
{{pthreads_timed_join()}} by wrapping the {{thr_proc}} in our own function and
having it signal (via
[{{pthread_cond_signal()}}|http://www.opengroup.org/onlinepubs/009695399/functions/pthread_cond_signal.html]
the sleeping thread (in a call to
[{{pthread_cond_timedwait()}}|http://www.opengroup.org/onlinepubs/009695399/functions/pthread_cond_timedwait.html])
just before exiting... Or is it overdesigning it? In any case, if you're happy
with the alarm() approach I'm okay with i
t.
> 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.
