Thoughts about future releases, in no particular order.
Feel free to share your thoughts with me at  mob@cpan.org .

Possible TODOs:

         wait     timeout
         waitpid  timeout
         waitall  timeout

		wait calls that block for only a limited time
         
         fork { stdin => \@STDIN }

		pass standard input to the child in a list at fork time.
                This seems more satisfactory for a  cmd  style fork that
                possibly can't wait for the parent to write to 
                Forks::CHILD_STDIN{$pid}.

         fork { stdout => \@output, stderr => \@error }

                when the child process completes, collect its stdout and stderr
                output into the specified arrays. This will conserve filehandles
                in the parent.

         fork { input_fh => [ 'X', 'Y', 'Z' ], output_fh => [ 'STDOUT', 'A' ] }

		open input and output filehandles in the child with the given names,
		accessible in the parent at something like $Forks::filehandles{$pid}{X}

         incorporate CPU load into system busy-ness calc (see Parallel::ForkControl)

	 incorporate free memory into system busy-ness calc (Parallel::ForkControl)

         implement child handles as sockets. May (or may not be) more robust
         than filehandles, or useful as backup when there are no more filehandles
	 available

	 implement child handles through IO::Pipe objects

         fork { callback => \&method }

                subroutine to call in the parent process when the child finishes

		callbacks for other events could also be considered:
			callback for a child starting
			callback for a child blocking
			callback for a child getting put on queue
			callback for a fatal error in child

         facilities to suspend jobs when the system gets to busy
         and to resume them when the system gets less busy.
         I bet this will be hard to do with Win32.

         fork { debug => $boolean }

                override $Forks::DEBUG for this job

         fork { cpu_affinity => $bitmask }

                <OLD POD>
                On supported systems with multiple cores, and after the successful
                creating of the child process, attempt to set the CPU affinity for
                the child process. $mask is typically a bitmask with the lowest level
                bits indicating whether the lowest numbered CPU's should be used
                by this process.
                </OLD POD>

         Currently USR1 is used to signal the program to analyze the queue.
         Make the signal configurable.

         Fully support changing process priority in Windows. Maybe this
	 can be done with Win32::Process .

	 Support for launching tasks on remote hosts (maybe that's beyond
         the scope of this module) See Paralell::PVM?

         fork { retries => $ntries }

		like Proc::Fork. Call CORE::fork() several times if
		it's not creating child processes.

	 fork { name => $name }

		Change ps() listing as in Parallel::ForkControl, or give
		another way to lookup a job object from Forks::Job::_get.