[BUG] reap_threads ignores delayed jobs

Hi,

Given the following jobfile:

[job1]
filename=job1file
size=16k
startdelay=1

... the job never starts because reap_threads() doesn't account for delayed
jobs in `pending'. Hence if there are no other pending jobs, the last line
of reap_threads() executes terminate_threads(), thus killing our poor
delayed job.

The following patch seems to fix the problem, but I'm not 100% sure on the
use of td->pid to always be zero for (and only for) pending jobs.

--
From: Aaron Carroll <aaronc_at_gelato.unsw.edu.au>
Subject: [PATCH] account for delayed jobs when reaping threads
reap_threads does not account for jobs that have been delayed
(e.g. via startdelay) which may lead to all threads being
terminated.  The following job file demonstrates the problem:
	[job1]
	filename=job1file
	size=16k
	startdelay=1
Signed-off-by: Aaron Carroll <aaronc_at_gelato.unsw.edu.au>
---
 fio.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/fio.c b/fio.c
index 355d873..6e25c5f 100644
--- a/fio.c
+++ b/fio.c
@@ -1024,7 +1024,11 @@ static void reap_threads(int *nr_running, int *t_rate, int *m_rate)
 		else
 			realthreads++;
-		if (!td->pid || td->runstate == TD_REAPED)
+		if (!td->pid) {
+			pending++;
+			continue;
+		}
+		if (td->runstate == TD_REAPED)
 			continue;
 		if (td->o.use_thread) {
 			if (td->runstate == TD_EXITED) {