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

Possible TODOs:

    ___ 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

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

	Consider a callback function that returns < 0 if an active job
	should be suspended, > 0 if a suspended job should be activated,
	and 0/undef if the job should be left in its current state

    _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 - failed CORE::fork calls usually indicate
                    some bad system condition (too many processes, out
                    of memory/swap space), so expectations of recovery
                    shouldn't be too high

    ___	configure during build. discover the maximum number of simultaneous
	processes that can be spawned and set MAX_PROC, DEFAULT_MAX_PROC.
	Could 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($$$$). Well,
        for interruption-resistant versions, anyway.

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

    _X_	Decompose source into manageable modules

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

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

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

    ___ in bg_eval and bg_qx, set 
	$Forks::Super::LAST_JOB_ID, $Forks::Super::LAST_JOB to access
	job information of a job launched from bg_eval or bg_qx.
	Bash users will recognize the similarity of capturing the
	$! variable in a bash script to capture the PID of the
	last background process that was launched.

	From there you can get state information, exit status,
	run times, or all kinds of good information about the job.

    ___ There's enough stuff in here now that performance is affected,
	especially when there are lots of short tasks. See what
	can be done to tighten up performance.

    ___ more OS features, max load, whether or not they are portable

    ___ $Forks::Super::Queue::QUEUE_MONITOR_FREQ can be a tied scalar
	that restarts the queue monitor process on update

	$Forks::Super::Queue::QUEUE_INHIBIT_MONITOR can be a tied scalar
	that calls kill_queue_monitor on update to zero.

	$Forks::Super::Queue::QUEUE_INTERRUPT can be (additionally) tied
	to restart queue monitor and reinstall signal handler on update

