System wide queue
-------------------------
You can set the $TS_SOCKET variable to the same name path for all your
'ts' processes, and then
they'll use the same socket for intercommunication. This means - single queue.
You should be certain that any 'ts' can read/write to that socket, using
chmod.


A queue for each resource
-------------------------
You can use $TS_SOCKET and aliases/scripts for having different queues for
different resources. For instance, using bash:
alias tsdisk='TS_SOCKET=/tmp/socket.disk ts'
alias tsram='TS_SOCKET=/tmp/socket.ram ts'
alias tsnet='TS_SOCKET=/tmp/socket.net ts'

You can also create shell scripts like this:
<< FILE ts2
#!/bin/sh
export TS_SOCKET=/tmp/socket-ts2.$USER
ts "$@"
>> END OF FILE ts2


Be notified of a task finished
-------------------------
In X windows, inside bash, after submitting the task, I use:
$ ( ts -w ; xmessage Finished! ) &


Killing process groups
-------------------------
ts creates a new session for the job, so the pid of the command run can be
used as the process group id for the command and its childs. So, you can use
something like:
$ kill -- -`ts -p`
in order to kill the job started and all its childs. I find it useful when
killing 'make's.


Limiting the number of ts processes
-------------------------
Each queued job remains in the system as a waiting process. On environments
where the number of processes is quite limited, the user can select the amount
of the maximum number of ts server connections to ts clients. That will be
read from the environment variable TS_MAXCONN at the server start, and cannot be
set again once the server runs:
$ ts -K     # we assure we will start the server at the next ts call
$ TS_MAXCONN=5 ts
Internally there is a maximum of 1000 connexions that cannot be exceeded without
modifying the source code (server.c).