TimeLimits
Related Docs:
object TimeLimits
| package concurrent
Executes the passed function, enforcing the passed time limit by attempting to signal the operation if the
time limit is exceeded, and "canceling" if the time limit has been
exceeded after the function completes, where what it means to "cancel" is determined by the implicitly passed Timed[T]
instance.
Executes the passed function, enforcing the passed time limit by attempting to signal the operation if the
time limit is exceeded, and "canceling" if the time limit has been
exceeded after the function completes, where what it means to "cancel" is determined by the implicitly passed Timed[T]
instance.
The Timed companion object offers three implicits, one for FutureOutcome, one for Future[U]
and one for any other type. The implicit Timed[FutureOutcome] defines cancelation as canceling the FutureOutcome:
no exception will be thrown. The implicit Timed[Future[U]] defines canceling as failing the Future[U] with a TestCanceledException:
no exception will be thrown. The implicit for any other type defines failure as throwing
TestCanceledException. For the details, see the Scaladoc of the implicit Timed providers
in the Timed companion object.
the maximimum amount of time allowed for the passed operation
a strategy for signaling the passed operation
a Prettifier for prettifying error messages
the Position of the caller site
the Timed type class that provides the behavior implementation of the timing restriction.
Executes the passed function, enforcing the passed time limit by attempting to signal the operation if the
time limit is exceeded, and "failing" if the time limit has been
exceeded after the function completes, where what it means to "fail" is determined by the implicitly passed Timed[T]
instance.
Executes the passed function, enforcing the passed time limit by attempting to signal the operation if the
time limit is exceeded, and "failing" if the time limit has been
exceeded after the function completes, where what it means to "fail" is determined by the implicitly passed Timed[T]
instance.
The Timed companion object offers three implicits, one for FutureOutcome, one for Future[U]
and one for any other type. The implicit Timed[FutureOutcome] defines failure as failing the FutureOutcome with a TestFailedDueToTimeoutException:
no exception will be thrown. The implicit Timed[Future[U]] defines failure as failing the Future[U] with a TestFailedDueToTimeoutException:
no exception will be thrown. The implicit for any other type defines failure as throwing
TestFailedDueToTimeoutException. For the details, see the Scaladoc of the implicit Timed providers
in the Timed companion object.
the maximimum amount of time allowed for the passed operation
the operation on which to enforce the passed timeout
a strategy for signaling the passed operation
a Prettifier for prettifying error messages
the Position of the caller site
the Timed type class that provides the behavior implementation of the timing restriction.
Trait that provides
failAfterandcancelAftermethods, which allow you to specify a time limit for an operation passed as a by-name parameter, as well as a way to signal it if the operation exceeds its time limit.The time limit is passed as the first parameter, as a
Span. The operation is passed as the second parameter. ASignaler, a strategy for interrupting the operation, is passed as an implicit third parameter. Here's a simple example of its use:The above code will eventually produce a
TestFailedDueToTimeoutExceptionwith a message that indicates a time limit has been exceeded:The code passed to failAfter did not complete within 100 milliseconds.If you use
cancelAfterin place offailAfter, aTestCanceledExceptionwill be thrown instead, also with a message that indicates a time limit has been exceeded:The code passed to cancelAfter did not complete within 100 milliseconds.If you prefer you can mix in or import the members of
SpanSugarand place a units value after the integer timeout. Here are some examples:The code passed via the by-name parameter to
failAfterorcancelAfterwill be executed by the thread that invokedfailAfterorcancelAfter, so that no synchronization is necessary to access variables declared outside the by-name.The
failAfterorcancelAftermethod will create a timer that runs on a different thread than the thread that invokedfailAfterorcancelAfter, so that it can detect when the time limit has been exceeded and attempt to signal the main thread. Because different operations can require different signaling strategies, thefailAfterandcancelAftermethods accept an implicit third parameter of typeSignalerthat is responsible for signaling the main thread.Configuring
failAfterorcancelAfterwith aSignalerThe
Signalercompanion object declares an implicitvalof typeSignalerthat returns aDoNotSignal. This serves as the default signaling strategy. If you wish to use a different strategy, you can declare an implicitvalthat establishes a differentSignaleras the policy. Here's an example in which the default signaling strategy is changed toThreadSignaler, which does not attempt to interrupt the main thread in any way:As with the default
Signaler, the above code will eventually produce aTestFailedDueToTimeoutExceptionwith a message that indicates a timeout expired. However, instead of throwing the exception after approximately 500 milliseconds, it will throw it after approximately 100 milliseconds.This illustrates an important feature of
failAfterandcancelAfter: it will throw aTestFailedDueToTimeoutException(orTestCanceledExceptionin case ofcancelAfter) if the code passed as the by-name parameter takes longer than the specified timeout to execute, even if it is allowed to run to completion beyond the specified timeout and returns normally.ScalaTest provides the following
Signalerimplementations:Signalerimplementationinterrupton the main test thread. This will set the interrupted status for the main test thread and, if the main thread is blocked, will in some cases cause the main thread to complete abruptly with anInterruptedException.wakeupon the passedjava.nio.channels.Selector, which will cause the main thread, if blocked inSelector.select, to complete abruptly with aClosedSelectorException.closeon thejava.io.Socket, which will cause the main thread, if blocked in a read or write of anjava.io.InputStreamorjava.io.OutputStreamthat uses theSocket, to complete abruptly with aSocketException.You may wish to create your own
Signalerin some situations. For example, if your operation is performing a loop and can check a volatile flag each pass through the loop, you could write aSignalerthat sets that flag so that the next time around, the loop would exit.