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"). [Do I need to start putting
		together a Sys::FreeMemory distribution, too?]

    _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

    ___	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  PERL_SIGNALS=unsafe make test .

	___ cygwin 5.10: occassionally failure, IPC litter
	___ linux: make test can hang

    ___ Make Forks::Super usable with v5.6.
	_X_ No  base
	_x_ No  Time::HiRes?
	___ MSWin32 5.6 ActiveState
	    ___ No  alarm
	    ___ No  socketpair
        ___ cygwin 5.6.1, failures in 40g,43a-f,44a-f,45
	    sockets and pipes work ok as standalone prog 
            (perl56 -Ilib t/43a-sockethandles.t) but not as a child process 
            (perl56 t/forked_harness.pl t/43a-sockethandles.t). So
	    "make test" works but "make fasttest" does not. Curious.
	    ___ No Cygwin::pid_to_winpid
	_X_ linux 5.6.2, failures in 41f, 42f
	___ linux make stresstest sometimes hangs
	    ___ failures related to overloading!  $job||1 idiom looks
                like trouble in child
	    I think we can live with intermittent failures for now.

    _x_	Make CONFIG{filehandles} meaningful. If we set CONFIG{filehandles}=0,
	then all IPC should be through sockets or pipes.
	___ Document? Come up with a better way to set this feature?

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

        Characterize some use cases for Forks::Super, and use settings
        appropriate to that use case. For example, if we use Forks::Super
        to manage many short tasks, we want to run the queue frequently
	and we want to use a short pause time. If we use Forks::Super to
	manage long, CPU-intense tasks, then frequent queue checks and
        brief pauses will make the Forks::Super module use up CPU that
	could be going to the tasks.

        ___ $FSU::DEFAULT_PAUSE short when tasks are quick,
            long when there are a lot of tasks
        ___ $FSQ::QUEUE_MONITOR_FREQ short when tasks are quick
        ___ $FSQ::QUEUE_MONITOR_LIFESPAN long or infinite for "daemon" programs
        ___ $FS::SOCKET_READ_TIMEOUT short for quick tasks
	___ $FS::MAX_PROC and ::DEFAULT_PROC to 1-1.5 times the number of
	    CPUs for CPU-intensive tasks; higher for IO bound tasks;
	    much higher for tasks with ample idle time

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

    ___ Test needed, Win32+cmd, See Job.pm:344 (404?) 
        (FSJO::Win32::openX_win32_process?)

    _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_ 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();
        _X_ works good. MAIN_PID doesn't get initialized until fork() call

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

    _o_ Tie all filehandles from _safeopen for improved debugging
	in Forks::Super::Job::IPC. 
	_x_ we are piling a lot of handle data into the symbol table now

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

	We'll streamline the way options are specified in 1.0

    ___ What other key-value pairs should FSJ::read_stdxxx handle?
	_X_ warn => 0|1

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

	Plans for Forks::Super::IPCChannel in 1.0 should handle this.

    ___ 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 ...
	___ signal list? trappable? "available"?
        ___ can use Time::HiRes::setitimer and a map of which ITIMER_xxx
            sets off which signal. We should use alternative to SIGALRM
            if possible.

    _X_ Reimplement F::S::Tie::BackgroundScalar to not require
	dereferencing. Say, by using overloading.

    ___ Hijack sleep function with FSU::pause or F::S::Uninterruptable::sleep?

    ___ Can we hijack  readline(;*)  and use a construction like  <$pid> ?

    _X_ Turn installation of bundled packages on by default for a couple
	of CPAN testing cycles. See what breaks.

	_X_ Enabled in v0.39

    ___ Keep the pipes clear:
        ___ During productive pauses, read and buffer input from all pipes
            connected to child process output streams. IO handles in the parent
	    are tied to some package that implements this functionality.

        ___ Harder: child processes have a subroutine to read and buffer
	    input from piped STDIN, and an out-of-the-way signal handler
	    to invoke the subroutine. During productive pauses in the
	    parent process, signal the child processes to run these
	    subroutines.

	___ On the write end of the pipe, we can also save extra output
	    in a buffer to be delivered at a more convenient time so that
	    the write operation doesn't block.

    ___ The IPC module needs to create a temporary directory that will
        be deleted when the program ends. Is there another module that
        has solved this problem better than I did?

    ___ Runtime IPC cleanup routine for long running programs. For long
	completed jobs: close the open filehandles that have slipped
	through the cracks; remove the IPC files; move from 
	%ALL_JOBS,@ALL_JOBS to %ARCHIVED_JOBS,@ARCHIVED_JOBS

    ___ Is it possible/desirable to use threads in place of "queue
	monitor process", "productive pause"?

    _X_ Does Forks::Super work in taint mode? Need some tests to make
	sure.

	Can run t/forked_harness.pl with  -p -t  or  -p -T  options.

    _x_ Make Win32::API a required module for MSWin32.

    ___ http://www.cpantesters.org/cpan/report/8376777 -- are there
	issues with Forks::Super and $ENV{LANG} == 'zh_TW.UTF-8'?
	utf issues?

	_X_ Vanilla utf8 seems ok. Running  t/forked_harness.pl  with
	    -p -Mutf8  passes.

    ___ IPC cleanup -- log fails and cleanse them off-line with
        perl -MForks::Super=cleanse   or
        perl -MForks::Super=cleanse=<directory>

    ___ Forks::Super::Job->reuse(%options) method to reuse a job
	object and its existing set of parameters; like calling
	fork { %{all_of_jobs_previous_options($job)} } but reusing
	the existing Forks::Super::Job object. It would be an
	error to call this unless the $job was completed.

    _x_ Time::HiRes::setitimer can deliver <XXX>arbitrary signals</XXX>SIGALRM
	at arbitrary times? Just what we need for dispatching the
	queue, "cleaning pipes", handling the asynchronous headaches
	of this module. Can we use this and retire the "queue monitor"?

	Maybe.
	___ _launch_queue_monitor() can set a SIGALRM handler and an itimer
	___ _kill_queue_monitor() can kill the SIGALRM handler and unset 
	    the itimer
	___ in a child with a timeout and CHILD_FORK_OK, we need to be a
	    little trickier.
	    Consider a list of functions to run in a signal handler that
	    can be added and removed at will.
	    ___ 00-pause productive pause code
	    ___ 01-runqueue check the queue
	    ___ 99-timeout child timeout code
	___ of course, verify that Time::HiRes::setitimer is available
	    and keep the fallback queue monitor method around.
	___ on solaris, we can only set one itimer.

	"Use of interval times may interfere with alarm(), sleep(),
	and usleep() ... anything may happen; it may work, it may not".

    _x_ For clarity. separate F::S::C config_module, config_component,
	config_external_program

    _O_ For organization, create F::S::XXX::Parent, F::S::XXX::Child
        modules, with function that are only to be executed in the
	parent or child.

	Parent and child specific modules can be 'require'd after a
	fork (or will this take too much time)? Parent modules can be
	unimported by the child.

	Since this looks like it might produce some overhead, make
	it a toggleable feature? (So don't use it when there are lots
	of small tasks?)

    ___ Document how to use $ENV{FORKS_SUPER_CONFIG}

    _X_ stresstest issues -- children launched by t/forked_harness die
	quickly (<0.1s) with status 139 (SIGSEGV + core dump) (Cygwin
        5.10 -- new signal handler may be to blame?)
	_x_ solution was don't erase the signal handlers in the child ...

    ___ unbundle Sys::CpuAffinity. At CPAN it shows that Sys::CpuAffinity
        module is part of Forks::Super distribution, which is true but
        it deemphasizes that it is also has its own distribution. I think
        the current configuration gets it less attention from
	CPAN testers, too.

