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

Possible TODOs:

    ___ 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

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

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

	Also document tips and tricks for tuning performance.
	Things like "Set $Forks::Super::Util::DEFAULT_PAUSE to
	a small value when you have lots of short tasks, and
	longer for longer tasks".

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

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

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

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

	Overload the Forks::Super::Job object to return the pid in
	a numerical context.

	Use cases:
	    _X_ $pid = fork { ... }
	    _X_ returns tied var to parent, scalar 0 to child, undef on error
	    _X_	$pid->state
	    _X_	$pid->status
            _X_ $pid->wait($timeout)
            _X_ $pid->kill($signal)
	    _X_ $pid->suspend, $pid->resume

	_X_ Document return value of fork, new methods on Forks::Super::Job

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

    ___ Tie scalar in parent to read end of a pipe? As child
	writes to the pipe, the scalar can be updated in
	the parent?

	Use case is  fork { stdout => $output }, and to be able
	to read/use intermediate $output values without having to
	wait for the child to finish.

	Prototype in spike-pipe-tie2.pl

	___ scalar is associated with a read handle and the job
	___ add scalar to a global list/set of pipes to read from
	___ on FETCH and during productive pauses, pull the most recent output
	___ on close in the parent, optionally kill the child process,
		close both the read and write ends of the filehandle

    ___ Tie all filehandles from _safeopen for improved debugging
	in Forks::Super::Job::IPC. 

    _X_ open2, open3 convenience methods [so.com/questions/3087263]
	that return filehandles, pid, and F::S::Job object.

    ___ block attribute or block value in child_fh attribute to
	indicate whether blocking I/O is desired.

    ___ 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_ test  fork { retries ==> max_retries } option. May need to mock it.

    ___ what else to configure at build time?
	___ e.g. "has Unixy signal framework"
	___ "is Windows"
	___ "is Windows/Cygwin"
	___ we can spoof this information for some tests ...

    ___ What should wait/waitall do when only suspended jobs are left?
	___ Currently we wait indefinitely. Document this.
	___ Document $Forks::Super::WAIT_ACTION_ON_SUSPENDED_JOBS override.

    ___ Now that it is more convenient to get a Forks::Super::Job object,
	what are some other useful methods for it?
	_x_ ->waitpid($flags[,$timeout])
	_x_ ->wait([$timeout])
	_x_ ->kill($signal)
	___ ->the_reason_that_the_job_aint_started_yet()
	___ ->close()
	___ ->write_stdin(@msg)
	___ ->read_stdout(\%options)
	___ ->read_stderr(\%options)
	___ "privatize" the more internal functions
	___ Document

    ___ In Forks::Super::Job 'overload' mode, should
	wait/waitpid also return overloaded Forks::Super::Job objects ?

    ___ Natural language extension to timeout, expiration, delay, 
	start_after options:

	___ fork { timeout => "10 minutes" }
 	___ fork { expiration => "8:00" }
 	___ fork { start_after => "midnight" }
	___ fork { expiration => "3:00 am Tuesday" }

    ___ Reimplement gensym() in Forks::Super::Job::Ipc to use
	safer 'Forks::Super::Symbol' package ?

    ___ Rework Forks::Super::LazyEval to use overloading rather
        than tied scalars. Use case is to be able to use
        $output rather than $$output.

v 0.35 task list

    Implement in Forks::Super::Job::Ipc:
	write_stdin
	read_stdout
	read_stderr
        Refactor in Forks::Super
	Forks::Super::Job::_resolve function.
    Refactor Forks::Super::Job::Ipc::close, close_fh
