stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: [jira] Updated: (STDCXX-536) allow thread safety tests to time out without failing
Date Tue, 11 Sep 2007 22:47:58 GMT
Travis Vitek wrote:
> 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.

Okay, this makes sense. I thought the patch would set a default
timeout of 295ms for every test and once reached, force it to
exit with a zero exit status. That would not be good.

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

Right. But tests whose threads that don't check the flag will
continue running and, presumably, be killed by the infrastructure.

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

How about implementing something more along the lines of what we
do with rw_opt_setlocales()? That way the whole command line option
handler along with the logic to set the alarm is in the driver,
and the tests that want to make use of it only need to add
&rw_opt_settimeout to the rw_test() call in main()?

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

I don't follow this. Why would the test want to reset the alarm?
Or do you mean set it in response to the command line option?

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

I see where you're going with this. You want the test to be able
to timeout, shut down all running threads when it does, and then
if there's more work to be done (i.e., another group of threads
to create), to reset the alarm and restart the whole process.

I guess I hadn't thought of the fact that some of these tests
create multiple thread pools. Hmm. I don't think the test should
be allowed to reset its own timeout but I'm not sure I see a good
solution. It certainly shouldn't exit successfully without doing
the rest of the work. Should it fail? Or should it just continue
with the next pool and allow itself to be killed?


> Travis
>> 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."
>> Thanks
>> Martin

View raw message