Enqueuing Runnables on a Server
You use the enqueue() member to enqueue a runnable for execution. Runnables can only be enqueued between calls to start() and stop(). Any attempt to enqueue a runnable before start() and after stop() produces an exception.
NOTE: This behavior is different from previous versions of the Threading package. Runnables that were enqueued while the server was not running were simply flushed and ignored prior to version 1.2.
The Threading package allows you to specify a
guard functor and a priority value for each runnable instance that you pass to a runnable server. Guard functors are defined in
Guard Functors.The priority value is used to establish the order in which unprocessed runnables should be considered for execution by the server. Runnables with higher priority values are evaluated and retrieved for execution before runnables of lower priority.
The capacity of a server’s input queue can be limited both at construction and by calling the setCapacity() member. If the capacity of the input queue is limited and the queue becomes full, then the enqueue operations block the caller until the server is able to process a sufficient number of runnables or until the capacity is increased. Each of the basic enqueue() functions is overloaded to give a form that includes a timeout argument. The timeout argument specifies the maximum amount of time to allow for the enqueue operation to complete.
Several functions in the Threading package accept a timeout value. This value is meant to specify the amount of “wall-clock” time, in milliseconds, that a function waits before timing out.
NOTE: In some situations, functions that accept a timeout value actually measure duration by the amount of CPU time used, not by the elapsed wall-clock time.
This may result in longer timeout periods than are expected or intended. In these situations, the amount of delay is directly proportional to the percentage of available CPU time granted to the process.
