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
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 wor
In the last episode (May 03), Chris Dillon said:
> On Tue, 2 May 2000, Dan Nelson wrote:
> > Aha. Yes, it _does_ do FIFO, but if you look at the source, the
> > queue sorting routine simply sorts on stat(mtime) of the queue
> > file, so jobs submitted in the same second will sort randomly. A
> >
On Tue, 2 May 2000, 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 chan
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 fil
At 2:09 PM -0600 5/1/00, Warner 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
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 program, printer type)?
Aha. Yes, it _does_ do
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
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 devia
I don't know if I make any strange mistake, but I
have done the following simple thing.
File p.c :
#include
FILE
*fp
;
main(){register int
i ;
for
(i=0;i<1000;i++)
{ fp=popen("lpr
-Plp","w"); fprintf(fp,"Richiesta
N. %d\n",i);
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 pre
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> program, printer
type)?
Yes, I think it's a very strange
behaviour.
In effect in the file
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
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
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 no
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 re
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, b
18 matches
Mail list logo
