Thoughts about future releases, in no particular order.
Feel free to share your thoughts with me at  mob@cpan.org 
or through  http://rt.cpan.org/NoAuth/Bugs.html?Dist=Forks-Super

Possible TODOs:

    _x_ support sockets/pipes for cmd-style forks like IPC::Open3 does.
	_X_ for Unixy systems
	___ for MSWin32
	    IPC::Open3 supports MSWin32/os2 with the <system 1, @_>
	    construction. Don't think that is appropriate for this module.

    ___ 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 24 fails in harness, passes standalone :-?
	_X_ linux 5.6.2, failures in 41f, 42f
	___ linux make stresstest sometimes hangs
	    _x_ 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?

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

    ___ fork { run => [ \@cmd, ... ] }
	to invoke or emulate IPC::Run's rich feature set
	___ What else can I learn by studying IPC::Run?

    ___ What other key-value pairs should FSJ::read_stdxxx handle?
	_X_ warn => 0|1
	_X_ timeout => max number of seconds to wait for input

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

	_X_ Enabled in v0.39
	_X_ Still enabled in v0.45
	___ Nothing breaks. Leave it.
 
    ___ The IPC module creates a temporary directory that will
        be deleted when the program ends. Is there another module that
        has solved this problem better than I did?
	_O_ File::Temp? Does this work on MSWin32?
	:-( File::Temp not robust enough when child procs outlive the parent.
	    Probably has NFS issues, too.

    ___ 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

    ___ Demos/examples/cookbook section.
        ___ Perform 1000's of jobs, 20 at a time
            ___ with queueing to perform other tasks
            ___ example: web crawler
	    _x_ example: multi-threaded du
        _x_ timeout long running jobs
        _x_ manipulate CPU affinities
        ___ dependencies
        ___ interactive client/server example of IPC
        _x_ see t/forked_harness.pl
        ___ load management
            ___ block while system is busy
            ___ suspend/resume
        ___ bg_eval, bg_qx examples
        ___ can_launch examples
        ___ how to: use sleep with Forks::Super
        ___ how to: use alarm with Forks::Super
        ___ changing IPC_DIR
        ___ tuning Forks::Super for fast jobs, slow jobs,
	    memory intensive jobs, cpu intensive jobs,
	    I/O bound jobs
        ___ scheduler app, running for days at a time
	___ reuse

    _x_ Forks::Super::Job::dispose( @jobs ) method
        _X_ Removes entry from @ALL_JOBS, %ALL_JOBS
	   ___ move to @ARCHIVED_JOBS, %ARCHIVED_JOBS?

    _x_ support stdin=>$input + child_fh=>socket or
                stdin=>$input + CONFIG(filehandles)==0
	___ t/25, t/42d, t/42i

    ___ POSIX::RT::Timer as possible replacement for get/set itimer?

    _-_ daemonize => 1  option to close/reopen STDxxx fhs to /dev/null,
        start a new process group, change directory to /.
        Disables IPC. Set umask to 0.
	See the Wikipedia daemon article to see all the requirements.
	A daemonized job cannot be signalled with Forks::Super::kill(job)
	___ how to test it?
	___ Will blanket close ruin sockethandles in the parent?
	___ Set the os_priority, cpu_affinity
	___ timeout, expiration?
	___ Then again, couldn't a daemon use most of the options to fork(),
	    including timeout, setting {real_pid}, etc.? Suppose that at 
	    the time a daemonized job is created, we create a small pipe
	    or other IPC channel for the child to tell the parent
	    what is the grandchild's PID ... 
        ___ Use Proc::Daemon if available? Any::Daemon
	___ Maybe this is something for 1.0 ...

    ___ Require Signals::XSIG. Bundle it?
        ___ The Default.pm module is not quite mature. Can't require
            Signals::XSIG while those tests are still part of the build.
        ___ Not practical to add functionality as workaround for Signals::XSIG
            not being available. Hard bundling would be ok, though. Or
	    copying the code into Forks::Super::Sighandler.

    ___ make SysInfo.pm.PL capable of managing config for multiple $^O,$]?
	Or more generally, what if the installed SysInfo.pm is set up for
	a different sys/version than the one that is actually being used?
	___ Some things are cheap to determine $SYSTEM/$VERSION/
	    $NUM_PROCESSORS(?)/all of %CONFIG; Others are expensive 
	    $MAX_FORK/$MAX_OPEN_FH/$SOCKET_CAPACITY/$PIPE_CAPACITY,
	    even $SLEEP_ALARM_COMPAT is not a cost you want to pay every
	    time the module is loaded.
	___ Can we detect all the versions of Perl that will use a module
	    installed a specific location? And run SysInfo.pm.PL for all
	    of them? I doubt it.

    ___ Fails t/20 t/21 on OpenBSD run as make test, but succeed as
	standalone? What's up with that?
	Intermittent failures.

    ___ Cygwin v5.13.9 runaway process during make?