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 CPU load into system busy-ness calc (see 
		Parallel::ForkControl) (Parallel::ForkControl uses uptime(1) 
		as  a "cheap linux only hack"
		See also: Win32::Process::CpuUsage, Sys::CPU, Sys::CpuLoad).

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

    ___ facilities to suspend jobs when the system gets to busy
        and to resume them when the system gets less busy.
        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_ fork { cpu_affinity => $bitmask }

                _X_ linux
		_X_ MSWin32
		___ BSD
		_X_ Cygwin
		_X_ documented
	 	___ Solaris
		___ Irix
		___ OS X
		___ any others ?

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

	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_	Decompose source into manageable modules

		Forks::Super::OS, Forks::Super::OS::XXX
		Forks::Super::Filehandle
		Forks::Super::Timeout
		Forks::Super::Uninterruptable
		Forks::Super::Depend

    ___	Forks::Super::Job::OS::XXX modules to implement
		set_os_priority
		    for Unixish sys (incl Cygwin) setpriority() does the job
		set_cpu_affinity
		    this is different for every OS
		get_cpu_load
		    most Unixes have uptime(1)
		    the specific C system calls are different
	for different kinds of systems.
	Also
		get_cpu_load

        _x_ OS::Win32
        _x_ OS::Linux -- first use of "conditional" Inline::C code
	___ OS::BSD
	___ OS::Solaris
	___ OS::Aix
	___ OS::Irix

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

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

    ___ 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_ A JSON-compatible bg_eval function for cases where JSON is
	available and YAML isn't

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

    ___ 0.27 is an issue fix release with emphasis on testing existing
    	features under load and on several different OS. The releases
        after that can focus on some new features that are straightforward
	to add (or at least to try) like
	    _X_	JSON to bg_eval
		$Forks::Super::OPEN_FH, more robust IPC
		cpu load
		hook up Sys-CpuAffinity
		suspend/resume feature
	    _X_ using pipes

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


