Xref: utzoo comp.unix.wizards:22298 comp.unix.i386:5601 comp.unix.xenix:11897
Path: utzoo!utgpu!watserv1!watmath!att!rutgers!psuvax1!brutus.cs.uiuc.edu!zaphod.mps.ohio-state.edu!van-bc!sl
From: sl@van-bc.wimsey.bc.ca (Stuart Lynne)
Newsgroups: comp.unix.wizards,comp.unix.i386,comp.unix.xenix
Subject: Re: lpadmin(8) question
Message-ID: <475@van-bc.wimsey.bc.ca>
Date: 4 Jun 90 21:26:41 GMT
References: <453@van-bc.UUCP> <1492@mitisft.Convergent.COM>
Organization: Wimsey Associates, Vancouver, B.C., Canada
Lines: 76

In article <1492@mitisft.Convergent.COM> dold@mitisft.Convergent.COM (Clarence Dold) writes:
>in article <453@van-bc.UUCP>, sl@van-bc.UUCP (Stuart Lynne) says:
>
>> Or that lpsched is designed to pay attention to having multiple destinations
>> some with the same physical device.
>
>There is no 'guard' within the lp subsystem.  Two print jobs could provide
>output to the same port simultaneously.
>
>What you might do is have the differing models attached to device /dev/null,
>as if they were remote printer models.  In the model, rather than a 
>cat to stdout, invoke an lp job to a printer with an unused name.
>We do this locally, with the default printer called "laser", a special model
>for UNIX - WordPerfect called "WPlaser", and both of them feeding output to
>a model called "RealLaser", which no one adresses directly.
>This results in a little overhead in extra processes, but allows for any 
>number of oddball printer models to be introduced transparently.

This method works fairly well but if the processing being done in the
interface coverts the output to something large (e.g. a fax getting
converted to a bitmap) then you end up having to store the intermediate
data. This can be unacceptable on smaller systems.

The other commonly suggested method is to implement a lock in the interface
script, so that no more than one process can proceed and output to the
physical device at one time.

For example the following script lplock, could be called from each interface
file:

	lplock `basename $0` $$

This script shows how this could be done, except that there is a race 
condition to create the lock file. 

A C program would be a much better solution.

# 
#   $1	The lp destination to be locked
#   $2  The process ID of the calling process
#
#   This script will check for the presence of a lock file 
#   		
#		/usr/spool/lp/LCK.device
#
#   Where device is derived from:
#
#		cat /usr/spool/lp/member/destination
#
#   If it exists the script will wait for the process number
#   from the file to exit and will then create a new file
#   with the supplied process ID.
#

printer=`basename $1`
id=$2

device=`cat /usr/spool/lp/member/$printer`
device=`basename $device`

#
while [ -f /usr/spool/lp/LCK.$device ]
do
    lock=`cat /usr/spool/lp/LCK.$device`
    while kill -0 $lock > /dev/null 2>&1
    do
	sleep 10
    done
    rm /usr/spool/lp/LCK.$device
fi

echo $id > /usr/spool/lp/LCK.$device


-- 
Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice)