Spotted queue processing error in ZMailer router..

[Matti Aarnio <matti.aarnio@sonera.fi>]

The thing was handling queue sort of right, except the child feeder
gave up when feeding busy child -- end result was that timeorder of

	A B C D E F G H I J K

got processed like:

	A B - - - - - - I - - 

	    - - - F - -   - -

etc.  ("-" meaning "skipped when no free child for job")

Rather badly, that is.  At VGER's large queue that was one of the
contributing factors for the slow processing we have seen.

I have been wondering recently why my workstation ZMailer system did
partial queue processing at times; meaning all messages in router
input directory were not processed in one go, but some were left behind.
I didn't realize the real reason before today when I spotted VGER's
routers processing some *new* message, while old ones were not yet
handled.     So I created a fixup for a subroutine which was called
by assuming it will block until processing is done, but which itself
assumed it won't block...


I really should rewrite the subprocess queue interaction thing in
the  router/daemonsub.c  module to behave much more in style of
what the scheduler does with its queues.  That could give also
processing priority mechanism.


/Matti Aarnio