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?

    _x_ support sockets/pipes for cmd-style forks like IPC::Open3 does.
	_X_ for Unixy systems
	___ for MSWin32

    _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?

    ___ 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 number of processors and
	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.

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

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

    _x_	$Forks::Super::Queue::QUEUE_INHIBIT_MONITOR can be a tied scalar
	that calls kill_queue_monitor on update to zero.
	___ add unit test

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

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

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

    _o_ $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_ With cmd and child_fh => "in" where cmd has pipes (cmd1 | cmd2),
	'<.fhfork/.fh_xxx' needs to go _before_ the first pipe
	_X_ solve basic case
	___ solve complicated case (where first pipe char might be a
	    quoted argument, or part of an argument).
	    e.g., what if the external command is
		perl -F/\\\|/ -ane 'BLOCK' < .fhforkXXX/.fh_XXX | ./other_prog

    _X_ Should we use IO::File->new_tmpfile instead of
	Forks::Super::Job::Ipc::_choose_fh_filename ?
	No. We generally need to write files in one process and read them
	in another.

    ___ fork { run => [ \@cmd, ... ] }
	to invoke or emulate IPC::Run's rich feature set

    ___ What else can I learn by studying IPC::Run?

    ___ Refactor fork return value to a tied scalar that 'fetch'es the
	pid but has the methods of the Forks::Super::Job object.

	Use cases:
		$pid = fork { ... }
		returns tied var to parent, scalar 0 to child, undef on error

