lpt0 blocking i/o causes ghostscript to hang system

[Peter C. Lai]

Hi. I have this peculiar issue with printing to lpt0 with ghostscript-gnu 7.05.

I'm running stock lpd(1) with a handwritten input filter. If I am printing a 
huge file (such that the printer can't buffer all of the document at once and I
am spooling to the printer as the printer is printing), and the printer starts 
blocking i/o (due to paper jam/paper out/etc), the ghostscript hangs the system
until I unblock the parport (by remedying the condition, or hitting the "retry"
button  on the printer). It appears that ghostscript attempting to pipe its
output trips interupts to the point that all of the cpu is taken up and the
system will stop responding until the printer unblocks lpt0.

My input filter is:

#!/bin/sh 
exec 3>&1 1>&2
GS=/usr/local/bin/gs
GS_FONTPATH=/usr/local/share/ghostscript/fonts:\ 
/usr/local/share/ghostscript/7.05/lib
export GS GS_FONTPATH
$GS -q -dNOPAUSE -dSAFER -sDEVICE=ljet4 -sOutputFile=/dev/fd/3 - && exit 0
exit 2

Now, if I don't use gs, and just use cat(1) as my passthrough filter like this:

#!/bin/sh
exec 3>&1 1>&2
/bin/cat 1>&3 && exit 0
exit 2

When i/o on lpt0 is blocking in this case, cat(1) will quietly sit there until 
such time that lpt0 can be written to again. I believe this is because cat(1)
buffers its output. 

Right now my solution is to have ghostscript's -sOutputFile=\|"/usr/bin/lpr -h \
-Pbuffer" where a printcap(5) entry for the "buffer" printer's device is lpt0
and has an input filter that uses cat(1) (just like above). Here, gs will
output the processed job to a "buffer" spool before any i/o is outbound to lpt0.

Any of you run into this problem at all? It was seriously bugging me until I
devised the 2 spooler system above, which adds stability to the system but
feels too hackish for me. Whereas my print server is no longer hanging because
someone is too lazy to put paper in it, the solution breaks my in-house web
based job control system.

The main culprit is gs not buffering its output; but lpd could also use a hand 
in "printer not-ready" detection.

-- 
Peter C. Lai
University of Connecticut
Dept. of Molecular and Cell Biology
Yale University School of Medicine
SenseLab | Research Assistant
http://cowbert.2y.net/