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. 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." > >https://issues.apache.org/jira/browse/STDCXX-536#action_12526315 > >Thanks >Martin > >
