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 }
    ___ fork { stdin => \$stdin }
    ___ fork { stdin => $stdin }

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

		With sub style, this needs a file descriptor but maybe
		not an open filehandle?

        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. But it doesn't allow you to read child 
		output while the child is running.

		Could implement this in terms of a "collect output callback".

        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::Super::CHILD_FH{$pid}{X}

        incorporate CPU load into system busy-ness calc (see Parallel::ForkControl)
		(Parallel::ForkControl uses uptime(1) as  a "cheap linux only hack"
		See also: Win32::Process::CpuUsage, Sys::CPU, Sys::CpuLoad).

	incorporate free memory into system busy-ness calc (Parallel::ForkControl)
		(Parallel::ForkControl says "non functional")

    ___	implement child handles through IO::Pipe objects

    _X_ 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

    _X_ fork { callback => { start => \&method, finish => \&method,
			     queue => \&method, fail => \&method } };

		subroutines to call in the parent process on various
		child process events

		XXX - Parallel::ForkManager names it "run_on_finish". We should
		consider the name  run_on_finish => CODE  or
		run on => { finish => CODE, start => CODE, ... }

    ___ 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.

    _x_ 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>

                _X_ linux [where /bin/taskset is avail]
		_X_ MSWin32
		___ BSD
		_X_ Cygwin
		_X_ documented
	 	___ Solaris
		___ Irix
		___ OS X
		___ any others ?

    _x_ Fully support changing process priority in Windows. This can be
	done with Win32::API and SetThreadPriority method. Takes on values
	between -2 and 2, or between -7 and 6 "if the thread has the
	REALTIME_PRIORITY_CLASS base class", whatever that is. (Oh, looks
	like we can use GetPriorityClass to figure out what it is).
        (See http://msdn.microsoft.com/en-us/library/ms686277(VS.85).aspx).

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

    _x_ fork { retries => $ntries }

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

    _X_ clean up temporary files. In some OS (MSWin32),
	     can't delete files from END block of parent if children
	     are still using those files. On those systems, wait for
	     children to finish.

	_X_ This is also a problem if the script is interrupted

        _X_ haven't observed this problem lately. How to reproduce?

    ___	configure during build. discover the maximum number of simultaneous
	processes that can be spawned and set MAX_PROC, DEFAULT_MAX_PROC.
	Would also be good to know the max number of open filehandles
	and plan around it.

	Forks::Super::Uninterruptable package for "uninterruptable" versions
	of Perl system calls like  sleep , connect , select($$$$)

    ___ Make Forks::Super safe(r) for unsafe signals (pre 5.7.3, see perlipc).
	Can test with >5.7.3 and Perl::Unsafe::Signals

    ___	Make CONFIG{filehandles} meaningful

    ___	Defect to fix, $Forks::Super::MAX_PROC = "0"

    ___	Decompose source into manageable modules

		Forks::Super::OS, Forks::Super::OS::XXX
		Forks::Super::Filehandle
		Forks::Super::Timeout
		Forks::Super::Uninterruptable

    _X_	exec => [ @args ]

	Use exec() instead of system() to run command. Child process
	doesn't return from fork(). Probably can't use  timeout/expiration.

    ___	kill_all($signal), kill($signal, @jobs)

	Deliver a signal to all jobs or to a list of jobs.

    _X_ a bg_eval { BLOCK } method, like forked in Acme::Fork::Lazy. 
	We could implement it in terms of a tied scalar or tied array

	_X_ implement
	_X_ test
	_X_ document
