CUPS: end-user usability issues

[Georgi Kuzmanov]

Another issue/question:

If printer aliases/exportable printer instances are emulated by several queues printing directly to the same network printer (for example, socket://ljet1:9100 ), the first job on each queue shows as "processing since..." and all other jobs show as "pending since...", whereas only one job could possibly be in the process of being sent at any one time to the JetDirect port of the printer in question.  Other than looking at the printer's output, is there a way to find out which job is actually getting printed at the moment?

And two related CUPS design questions:
==============================
1. When jobs reach a printer via different paths (such as in the example above), is there any real coordination between the queues, or do they just fight it out so the first queue to get a hold of an open socket to port 9100 of that printer gets to send its job first?  What happens if the two or more queues are on two or more print servers?  What is the mechanism which decides the sequence in which jobs 1a, 2a, 3a coming through CUPS server A and jobs 1b, 2b, 3b, 4b, 5b, 6b and 7b coming through CUPS server B will get printed?

2. If an accounting script for job "1a" from CUPS server A gets a reading of the page counter by sending a PS or PCL print job "before1a" before job 1a and PS or PCL job "after1a" and an accounting script for job "2b" form CUPS server B gets a reading of the page counter through job "before2b" before, and again through job "after2b" after it has sent job 2b, is there a possible racing condition, or is there a mechanism that could guarantee the jobs will be sent in the order:

"before1a - 1a - after1a - before2b - 2b - after2b"

instead of, for example,

"before2b - before1a - 1a - after1a - 2b - after2b"

which would accidentally count the pages of job 1a for job 1a and the pages for both jobs 1a and 2b for job 2b?