At 7:56 AM -0500 5/3/00, Chris Dillon wrote:
That isn't the problem. You can sleep as much as you want between
submitting the print jobs and the job order still gets munged.
Even a job that at one time had #1 rank gets inverted and ends up
with the lowest rank.
He's saying that you could work
On Wed, 3 May 2000, Garance A Drosihn wrote:
With the update I made, the sort will be stable because the two
filenames will not be equal. Please try the update at:
http://www.freebsd.org/cgi/query-pr.cgi?pr=18361
[PATCH] Fix for queue-ordering problem in lpr/lpd/lpq
or pick up
I don't know if I make any strange mistake, but I
have done the following simple thing.
File p.c :
#include stdio.h
FILE
*fp
;
main(){register int
i ;
for
(i=0;i1000;i++)
{ fp=popen("lpr
-Plp","w"); fprintf(fp,"Richiesta
N. %d\n",i);
pclose(fp);
}}
then
cc -o p p.c
./p
the
Submitting the files with a single command should prevent reordering.
lpc's topq command can be used to move a job to the top of the queue.
Printing small jobs first is a desirable feature. Too often I've
found a dozen people waiting while large jobs tied up the printers and
that user wasn't
Warren Losh wrote:
LPR queues up the reuqests and prints them in order smallest to
largest to reduce the average wait time for a job at the expense of
having a larger standard deviation in the wait times for jobs. Maybe
this is what you are running into. I don't know if there's a way to
Konrad Heuerwrote
Hmm, I've never seen such a strange behaviour.
Lpd should do FIFO. Could you give some more infos about your
environment (os release, input filter program, printer
type)?
Yes, I think it's a very strange
behaviour.
In effect in the file
On Tue, 2 May 2000, Konrad Heuer wrote:
On Tue, 2 May 2000, Lorenzo Iania wrote:
Warren Losh wrote:
LPR queues up the reuqests and prints them in order smallest to
largest to reduce the average wait time for a job at the expense of
having a larger standard deviation in the
I'd bet it does, quicksort is not a stable sort and all of
your print requests are the same length.
-Ira
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
At 5:47 PM -0500 5/2/00, Dan Nelson wrote:
In the last episode (May 02), Chris Dillon said:
On Tue, 2 May 2000, Konrad Heuer wrote:
Hmm, I've never seen such a strange behaviour. Lpd should do FIFO.
Could you give some more infos about your environment (os release,
input filter
At 8:37 PM -0400 5/2/00, Garance A Drosihn wrote:
This should not break anything. I will write up an update which
does this, unless someone thinks it is a BadIdea(tm) for some reason.
Someone else would have to commit the change to the official source,
but at least Lorenzo could try that change
On Tue, 2 May 2000, Lorenzo Iania wrote:
Warren Losh wrote:
LPR queues up the reuqests and prints them in order smallest to
largest to reduce the average wait time for a job at the expense of
having a larger standard deviation in the wait times for jobs. Maybe
this is what you are
LPR queues up the reuqests and prints them in order smallest to
largest to reduce the average wait time for a job at the expense of
having a larger standard deviation in the wait times for jobs. Maybe
this is what you are running into. I don't know if there's a way to
disable this behavior or
I have the following problem using lpr:
when the number of consecutive requests grow, they are not printed in the
same order. This happens on several versions from 2.2.7 to 3.4. All the
requests are printed, but the order is not the same of the requests.
Effectively the order is initially right,
At 4:40 PM +0200 4/28/00, Lorenzo Iania wrote:
I have the following problem using lpr:
when the number of consecutive requests grow, they are not printed in the
same order. This happens on several versions from 2.2.7 to 3.4. All the
requests are printed, but the order is not the same of the
14 matches
Mail list logo
