[bug-pcl] /dev/random delays in pcl6 on AIX 5.2

[Henry Stiles]

Thanks we'll pass this along to the ghostscript folks since it affects
code pcl borrows directly from ghostscript.  They have a pretty long
list of problems and commercial users are helped before free users so
I don't know when it will get addressed.

Could you post your AIX makefile for building PCL to the mailing
list for other users?  Thanks.

Paul Lechnar writes:
 > Hi guys.
 > 
 > The following is a description of a delay problem in pcl6, which has 
 > been solved.  My solution is at the end.  Discussion follows:
 > 
 > We've been using pcl6 in an AIX 5.2 production environment successfully 
 > for about 3 months now.  Just recently, however, we've started to create 
 > about 10 pdf's from source PCL files in rapid succession.  This led to 
 > behavior in pcl6 I hadn't noticed before:
 > 
 > 1.  The first pcl file is converted in less than 1 second.
 > 2.  Subsequent runs of pcl6 take between 50-60 seconds to complete
 > 3.  If you wait 2 minutes  and then run pcl6 it will finish immediately.
 > 
 > So, I investigated using the wonderful "truss" tool in AIX.  This tool 
 > is similar to "strace" in linux, which will allow you to follow system 
 > calls made by a program as it runs.  You use it like:
 > 
 > $  truss pcl6 <args>
 > 
 > Output is VERY verbose, so you can redirect to a file like
 > 
 > $ truss -o output.txt pcl6 <args>
 > 
 > Anyway, truss showed that the delay occured just after an fopen() on the 
 > /dev/random file.  This is a psuedo-random number generator (PRNG) in 
 > AIX and many other UNIX operating systems.  Looks like pcl6 is trying to 
 > get some random binary data to use for some function or other, and the 
 > first time it runs there is some data ready to be read, but subsequent 
 > calls have a significant delay before more random stuff is ready to be read.
 > 
 > In AIX, the /dev/random PRNG is "cryptographically strong", which has 
 > the side effect of being easily exhausted and slow to replenish.  There 
 > is another device file, /dev/urandom (with a "u" in front) which provide 
 > a steady stream of data.  I know this file also exists in linux, it may 
 > be in other UNIXes too.  I decided to change what pcl6 uses as a random 
 > number source and see if the problem goes away.
 > 
 > FIX:
 > A search of the ghostpcl source tree located 2 references to 
 > /dev/random, both in the directory gs/src.  They are "gdevpdf.c" and 
 > "gdevpdf2.c".  There is a short fread() of some data around line 505, to 
 > populate the pdev->random_offset structure.  I Changed the fopen() 
 > system call to use /dev/urandom in 1 place in each file and recompiled.
 > 
 > This new pcl6 binary works flawlessly with up to 100 consecutive runs.  
 > I don't think I'll be running it more continuously than that.
 > 
 > Based on comments in the source code, I don't think the random data has 
 > to be crypto-grade strong, so using urandom shouldn't compromise the 
 > program's operation (there is reference to using the system date if 
 > /dev/random is not available).
 > 
 > Hope this helps anyone else experiencing delays
 > 
 > Paul
 > 
 > _______________________________________________
 > bug-pcl mailing list
 > bug-pcl at ghostscript.com
 > http://www.ghostscript.com/mailman/listinfo/bug-pcl

-- 
./Henry
Artifex Software