#13 fix compile and runtime bugs on fedora/redhat system

[Koni]

The attached patch fixes some compile problems and
several runtime bugs with the queue-stable branch of
CVS, at least for GNU/Linux, specifiyically Fedora Core 3.

If you are trying to compile on recent release (April
2005 when I write this) GNU/Linux system, you will find
the 1.40 beta release of "queue-stable" does not work,
but its not just compile problems.

First, make sure you checkout from cvs through
sourceforge the queue-stable module -- the release file
has autoconf/automake problems, I am not competent to
handle these things. The cvs version, at the time I
write this, did not have autoconf/automake problems.

After the patch, you will still see warnings about
setsigmask() being deprecated, if it is still 2005 you
can probably ignore that. This will take some time to
deal with that I don't want to bother with unless there
are no active developers left for this project.

The patch fixes the following runtime problems, in
addition to allowing compilation:

There is a race condition for quickly executing jobs
(see comment in the code). I put in a hack that seems
to address the phenotype of hung queued children, but
it doesn't properly solve the problem. Its a design
issue, this silly hack I put in just makes the child
process sleep a little so the parent can win the race.
Your mileage may vary.

The pty stuff is totally broken on linux, but it seems
to be because more recent linux systems have /dev/pts
now, but it doesn't look like anyone has done much with
it since around 1998 or so and it doesn't know what
filenames to search for in /dev. I added a function
that wraps allocpty() to use openpty() which was added
to glibc around 2003.

The resource limit stuff, RLIMIT and rtab[] in the code
do not match the linux header files. There are way more
RLIMIT #defines than are recognized by the profile
thing in GQ. As I found the code, it would exit fatally
because RLIM_NLIMITS is larger than the limits defined
by rtab[]. I switched this to a debug warning. limit
codes that are unknown to the hardcoded rtab table are
ignored now and queued can actually start jobs. The
functionality of the rlimit stuff may be horribly
broken though, I don't intend to use the feature myself
anytime soon, so don't think that it's fixed, it just
doesn't stop everything from running now.

Hope that helps someone. Has nobody used this thing in
years? Seems hard to believe. The documentation at
www.gnuqueue.org makes it seem like it was once an
excellent program.