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}

    _X_ incorporate CPU load into system busy-ness calc

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

    _X_ implement child handles through pipe objects
	___ use IO::Pipe
	_X_ document, extend file vs. socket discussion
	    On MSWin32, for example, pipe capacity is 512 bytes?

    ___ support sockets/pipes for cmd-style forks like IPC::Open3 does.

    _x_ facilities to suspend and resume jobs 

	either suspend/resume based on the busyness of the system
	or on demand. 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_ How should we suspend/resume jobs on the queue? By
	    having the additional job state "SUSPENDED-DEFERRED"

	What if the child process is trapping SIGSTOP? For now that's
	not my problem. Maybe we can ask the operating system if the
	process is suspended.

    _x_ What should  wait  and  waitall  do when only suspended jobs
        are left?

	When only deferred jobs are left, that is ok. We will wait
	indefinitely until something triggers the jobs.

	Some possibilities:

	1. carp and return  constant ONLY_SUSPENDED_JOBS_LEFT => -1.75

        2. resume one job. Repeat as necessary.

        3. wait indefinitely. Statistics show that civilizations will
	   rise again. There will once again be lemon soaked paper napkins.

	_X_ by default we'll go with option 3. An undocumented feature is
	    to set $Forks::Super::Wait::WAIT_ACTION_ON_SUSPENDED_JOBS
	    to change the default behavior.

	___ change this feature to documented?

    _X_ fork { cpu_affinity => $bitmask }

    _X_ All the work on creating a portable front-end to setting CPU
	affinity would make a great Sys::CpuAffinity module

    _X_ Something to portably count the number of cpu's is good, too.

    ___ 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 (mock?)
		_X_ 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. If we set CONFIG{filehandles}=0,
	then all IPC should be through sockets or pipes.

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

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

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

	_X_ document
	_X_ handle things in Forks::Super context
	    _X_ INT,QUIT,TERM etc. on DEFERRED jobs can cancel them
	    _X_ INT,QUIT,TERM etc. on SUSPENDED jobs can restart them and then kill them
	    _X_ STOP on an ACTIVE job will change state to SUSPENDED
	    _X_ CONT on a SUSPENDED job will resume it
		(do we need to implement suspend/resume
	    _X_ Special handling for pseudo procs on Windows

    ___ 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

    _X_ Better EXPORTS documentation in pod.

    ___ Test needed, Win32+cmd, See Job.pm:344

    ___ Investigate apparent incompatibility with Win32::API, perl 5.12.0

    ___ $Forks::Super::OPEN_FH to track the number of open filehandles
        (opened by Forks::Super::XXX modules, not the total number)

        Be a little robust when IPC setup fails because of too many open
	filehandles. Pause and retry; close the "oldest" filehandles?

    _X_ On Unix test 60-os, skip priority tests is priority is already 20
        (meaning the test is already being conducted in super nice mode
        and the priority can't be changed ...)

    ___ With cmd and child_fh => "in" where cmd has pipes (cmd1 | cmd2),
	'<.fhfork/.fh_xxx' needs to go _before_ the first pipe
