case class NegativeTimeout(t: Timeout) extends Product with Serializable
Instance Constructors
- new NegativeTimeout(t: Timeout)
Value Members
- final def !=(arg0: Any): Boolean
- final def ##: Int
- final def ==(arg0: Any): Boolean
- final def asInstanceOf[T0]: T0
- def clone(): AnyRef
- final def eq(arg0: AnyRef): Boolean
- final def getClass(): Class[_ <: AnyRef]
- final def isInstanceOf[T0]: Boolean
- final def ne(arg0: AnyRef): Boolean
- final def notify(): Unit
- final def notifyAll(): Unit
- def productElementNames: Iterator[String]
- final def synchronized[T0](arg0: => T0): T0
- val t: Timeout
- final def wait(arg0: Long, arg1: Int): Unit
- final def wait(arg0: Long): Unit
- final def wait(): Unit
Deprecated Value Members
- def finalize(): Unit
Inherited from Product
Inherited from Equals
Inherited from AnyRef
Inherited from Any
How long we should wait for something that we expect *not* to happen, e.g. waiting to make sure that a channel is *not* closed by some concurrent process.
NegativeTimeout is a separate type to a normal Timeout because we'll want to set it to a lower value. This is because in normal usage we'll need to wait for the full length of time to show that nothing has happened in that time. If the value is too high then we'll spend a lot of time waiting during normal usage. If it is too low, however, we may miss events that occur after the timeout has finished. This is a necessary trade-off.
Where possible, tests should avoid using a NegativeTimeout. Tests will often know exactly when an event should occur. In this case they can perform a check for the event immediately rather than using using NegativeTimeout.