stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <>
Subject RE: [jira] Updated: (STDCXX-536) allow thread safety tests to time out without failing
Date Tue, 11 Sep 2007 19:05:23 GMT

Ah, maybe there was some miscommunication in our phone conversation on
Friday. When we were talking about this, I mentioned adding a little bit
of code to main for the command line argument stuff, and a little code
to the thread_func to check the flag in each multithreaded test. You
responded that as much of the common stuff should be pushed into the
driver as possible and that the only thing that should be changed in the
tests is the polling of the 'timeout' flag.

That is essentially what I've done here.

Whatever timeout period you specify to --timeout-period=<N> will be the
number of seconds [remember rw_alarm uses seconds not milliseconds] that
will elapse before the _rw_timeout_expired flag will be set to a
non-zero value. After all of the command line arguments have been
processed, the driver calls _rw_runopts_timeout() which will setup the
alarm. After N seconds have elapsed the flag will be set and the polling
threads should see that and exit early.

After stepping back and thinking about how it probably should work, I've
got some thoughts. I think that the changes to the driver should be
eliminated. If the user wants this timeout stuff in their multithreading
test, then they have to add a hook in the command line arg processing
stuff in main [just like they do for the --nthreads arg]. There would be
one command line argument --timeout that will set the timeout period.
>From there I see a choice. Either the test can be expected to explicitly
start/reset the alarm timer [via rw_timeout_start/stop() maybe], or it
could be done implicitly within the rw_thread_pool() function. Either
way, before the threads are started the _rw_timeout_expired flag would
need to be cleared and the alarm would need to be set. After all threads
had exited, the alarm would need to be cancelled.

This way each section of the test would use the provided timeout. The
timeout could still have a default value of 30 seconds if we wanted the
tests to use this without needing to supply additional command line
parameters to them from the build system.


>Martin Sebor wrote:
>Hi Travis,
>Can you describe how this all works? I.e., what happens to a test
>invoked without the --timeout option when it exceeds the default
>295ms timeout? What happens to one that is invoked with the option?
> From your comment below it sounds like the solution you implemented
>is different from what I described in the issue, i.e., "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."

View raw message