From owner-freebsd-hackers Tue May 2 10:53:43 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from elisa.utopianet.net (elisa.utopianet.net [212.210.231.2]) by hub.freebsd.org (Postfix) with ESMTP id 0552D37BB8E for ; Tue, 2 May 2000 10:53:32 -0700 (PDT) (envelope-from l.iania@sintesi.net) Received: from lorenzo (giorgia.sintesi.net [212.210.231.9]) by elisa.utopianet.net (8.9.1a/8.9.1) with SMTP id TAA18402 for ; Tue, 2 May 2000 19:53:17 +0200 (CEST) Message-ID: <001401bfb45f$a16978c0$0500000a@sintesi.intr> Reply-To: "Lorenzo Iania" From: "Lorenzo Iania" To: Subject: Re: lpr: order of print requests Date: Tue, 2 May 2000 19:55:40 +0200 Organization: S.IN.TE.S.I. Srl MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01BFB470.64A5FD80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0011_01BFB470.64A5FD80 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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=3D0;i<1000;i++) { fp=3Dpopen("lpr -Plp","w"); fprintf(fp,"Richiesta N. %d\n",i); pclose(fp); } } then cc -o p p.c ./p the result of lpq after this is: waiting for lp to become ready (offline?) Rank Owner Job Files Total Size 1st root 33 (standard input) 15 bytes 2nd root 30 (standard input) 15 bytes 3rd root 35 (standard input) 15 bytes 4th root 36 (standard input) 15 bytes 5th root 29 (standard input) 15 bytes 6th root 31 (standard input) 15 bytes 7th root 37 (standard input) 15 bytes 8th root 38 (standard input) 15 bytes 9th root 39 (standard input) 16 bytes 10th root 40 (standard input) 16 bytes 11th root 41 (standard input) 16 bytes 12th root 42 (standard input) 16 bytes 13th root 32 (standard input) 15 bytes 14th root 34 (standard input) 15 bytes 15th root 56 (standard input) 16 bytes 16th root 57 (standard input) 16 bytes 17th root 43 (standard input) 16 bytes ....etc As you can see, the first on the queue is Job 33, while the second is 30 = and so on .... The sizes are irrilevant because they are the same. For this reason, and for similar problems, it is desiderable that the = order of the requests is the same. I think that must be a chance to = respect the order of the requests to avoid situations like this. Thanks. ------=_NextPart_000_0011_01BFB470.64A5FD80 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I don't know if I make any strange = mistake, but I=20 have done the following simple thing.
 
 
File p.c :
 
#include <stdio.h>
 
FILE   =20 *fp           &nbs= p;=20 ;
 
main()
{
register = int   =20 i       ;
 
for=20 (i=3D0;i<1000;i++)
       =20 {
        fp=3Dpopen("lpr=20 -Plp","w");
        = fprintf(fp,"Richiesta=20 N. %d\n",i);
       =20 pclose(fp);
       =20 }
}
then
 
cc -o p p.c
 
./p
 
the result of lpq after this = is:
 
waiting for lp to become ready=20 (offline?)
Rank   Owner      = Job =20 Files           &n= bsp;           &nb= sp;        =20 Total Size
1st    = root      =20 33   (standard=20 input)           &= nbsp;         =20 15 bytes
2nd    = root      =20 30   (standard=20 input)           &= nbsp;         =20 15 bytes
3rd    = root      =20 35   (standard=20 input)           &= nbsp;         =20 15 bytes
4th    = root      =20 36   (standard=20 input)           &= nbsp;         =20 15 bytes
5th    = root      =20 29   (standard=20 input)           &= nbsp;         =20 15 bytes
6th    = root      =20 31   (standard=20 input)           &= nbsp;         =20 15 bytes
7th    = root      =20 37   (standard=20 input)           &= nbsp;         =20 15 bytes
8th    = root      =20 38   (standard=20 input)           &= nbsp;         =20 15 bytes
9th    = root      =20 39   (standard=20 input)           &= nbsp;         =20 16 bytes
10th   root      =20 40   (standard=20 input)           &= nbsp;         =20 16 bytes
11th   root      =20 41   (standard=20 input)           &= nbsp;         =20 16 bytes
12th   root      =20 42   (standard=20 input)           &= nbsp;         =20 16 bytes
13th   root      =20 32   (standard=20 input)           &= nbsp;         =20 15 bytes
14th   root      =20 34   (standard=20 input)           &= nbsp;         =20 15 bytes
15th   root      =20 56   (standard=20 input)           &= nbsp;         =20 16 bytes
16th   root      =20 57   (standard=20 input)           &= nbsp;         =20 16 bytes
17th   root      =20 43   (standard=20 input)           &= nbsp;         =20 16 bytes
....etc
 
As you can see, the first on the queue = is Job 33,=20 while the second is 30 and so on ....
The sizes are irrilevant because they = are the=20 same.
For this reason, and for similar = problems, it is=20 desiderable that the order of the requests is the same. I think that = must be a=20 chance to respect the order of the requests to avoid situations like=20 this.
 
Thanks.
 
 
------=_NextPart_000_0011_01BFB470.64A5FD80-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message