Backend processing

The backend for a queue is begun by qdaemon; the qdaemon determines that a job's turn to be processed has arrived, sets up an execution environment for the queue backend, constructs an argument vector for the backend, and, via fork and exec, causes the backend to begin execution.

The number of simultaneous instances of the backend is controlled by the presence or absence of the file parameter in the stanza for this queue in the /etc/qconfig configuration file. If the file parameter is present, then only one instance of the backend can exist for this queue; This is because the qdaemon will only attempt to set the execution environment for the backend when it has determined that the job can be processed. Part of setting the backend's execution environment involves opening stdout of the backend onto the file or device specified by the file parameter. If the qdaemon has already performed this action for a previous job, and that job is still executing, then the qdaemon cannot get a lock on the file or device specified by the file parameter and hence cannot open stdout of the backend onto that file or device. Thus the qdaemon holds the job in the queue and waits for the previous job to complete execution and release the file or device. This is how the spooling system provides and controls serial access to a device.

If the file parameter is absent or set to a value of FALSE, the qdaemon opens stdout of the backend onto /dev/null and executes the job immediately. In this situation there is no clear file or device to which serial access should be provided, so jobs will not stack up on the queue. Jobs submitted to this queue will be processed just as fast as the qdaemon can set up the execution environment. The absence of the file parameter effectively disables serial access to any local file or device.

A meaningful and common example of a queue lacking the file parameter is a remote printer queue. In this situation, the resource to which serial access should be provided actually exists on another host; there is no reason for the local queue to attempt any type of control. The backend for this type of queue, by default the rembak program under the base operating system, simply sends the job across the network to the remote queue and lets it handle the serial access control.

The default backend for a local print queue under the base operating system is piobe. Multiple queues can all specify the same backend. In this situation, multiple simultaneous instances of piobe can exist; each queue that specifies piobe as its backend can potentially generate an instance of piobe. However if two or more queues also specify the same value for the file parameter, the serial access restriction is applied. The qdaemon will not be able to acquire a lock on the specified file or device if the qdaemon has already acquired the lock for another instance of piobe. A queue that cannot process a job because of this restriction will show a queue status of DEV_BUSY. The status will change to RUNNING as soon as the qdaemon can acquire a lock on the file specified by the file parameter.