3.10 Timeout Management

When such a timeout has been specified for some operation, the scheduler will resume the execution of that operation if it gets the control and the timeout period has expired. This means that lots of activity in the system as a whole may postpone the detection of a timeout somewhat, and - as usual - an infinite loop somewhere could stop everything.

In practical terms, the operation is resumed when and if the timeout period expires, and of course it resumes by executing an error callback. Two different error callbacks may be used to indicate the problem. If no irreversible actions have been taken, the timedOut error callback is used. If some irreversible actions have been taken, such as receiving or sending part of a message, the timedOutInTransfer error callback is used. This last situation is considerably more grave than the first: Aborting an operation in-transfer means breaking the protocol, which again means that any subsequent messages received on the same connection will be garbled. Resynchronization is hardly possible unless the data transferred are lines of text or some other format with built-in structural markers. So in this situation, give it another chance, or close the connection.

For streamSocket the socket level attribute timeoutValue decides the timeout for all operations inherited from stream. For binarySocket each operation which has timeout control takes the timeout value as its first enter parameter. Likewise with socketGenerator. If you forget to specify such a timeout value, the operation will always terminate at once with a timeout error.