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

[Paul Lechnar]

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