Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 2 May 2000 20:37:44 -0400
From:      Garance A Drosihn <drosih@rpi.edu>
To:        Dan Nelson <dnelson@emsphone.com>, Chris Dillon <cdillon@wolves.k12.mo.us>
Cc:        Konrad Heuer <kheuer@gwdu60.gwdg.de>, Lorenzo Iania <l.iania@sintesi.net>, freebsd-hackers@FreeBSD.ORG
Subject:   Re: PROBLEM FOUND (sort of): Re: lpr: order of print requests
Message-ID:  <v04210102b5352013f4e3@[128.113.24.47]>
In-Reply-To: <20000502174713.A14919@dan.emsphone.com>
References:  <Pine.BSF.4.05.10005021716540.3805-100000@gwdu60.gwdg.de> <Pine.BSF.4.20.0005021309580.92225-100000@mail.wolves.k12.mo.us> <20000502174713.A14919@dan.emsphone.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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 program, printer type)?
>
>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 quick fix would be
>to sleep for 1 second between "lpr" calls.

I would call that more of a "workaround" than a "fix"...  :-)

For the example situation that Lorenzo is talking about, a quick fix to
lpr might be to change the compar() routine in common_source/common.c.
The code should probably check for the case where two files have the
same last-modification time (to the degree of accuracy that stat() can
tell the last-mod time), and if they match then the routine should sort
the cf files based on the file-name.  That means 'cfA001some.host.name'
would always come before 'cfA002some.host.name', so it solves the
problem when jobs area all coming from the same hostname, except for
the case where the jobid wraps around from '999' to '000'.  Probably
could handle that case easily enough, too, with a little extra thought.

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 and see if it helps his
situation.

Given the example he gave in a different message, I am not completely
convinced that this is the problem he is seeing.  Still, this change
does seem like a good idea to do.


---
Garance Alistair Drosehn           =   gad@eclipse.acs.rpi.edu
Senior Systems Programmer          or  drosih@rpi.edu
Rensselaer Polytechnic Institute


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v04210102b5352013f4e3>