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

    ___ suspend/resume callback function

	run periodically on all active AND suspended jobs
	if return value < 0, then active job is suspended
	if return value > 0, then suspended job is resumed
	if return value == 0, then stay in current state

    _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

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

    ___ Tests for tied scalar behavior of
	___ $Forks::Super::Queue::QUEUE_MONITOR_FREQ
	___ $Forks::Super::Queue::QUEUE_INHIBIT_MONITOR
	___ $Forks::Super::Queue::QUEUE_INTERRUPT

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

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

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

    ___ 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
		$pid->state;
		$pid->status;

	This might not be possible.

    ___ More information to Forks::Super::SysInfo.
	___ e.g. "has Unixy signal framework"
	___ "is Windows"
	___ "is Windows/Cygwin"
	___ we can spoof this information for some tests ...

    ___ More tests from a child process and see what breaks.
		use Forks::Super;
		CORE::fork() && exit;
		# now $$ != $MAIN_PID but this is the
		# "parent" process of Forks::Super.
		do_something_and_see_if_it_works();

    _o_ Investigate "filehandle leaks" in t/forked_harness.pl.
