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
        _X_ don't know specifically what I did, but 
            PERL_SIGNALS=unsafe make test/fasttest are usually successful now,
	    at least for v0.49
	    

    _O_ Make Forks::Super usable with v5.6.
	My 5.6 test environments are getting difficult to maintain.

    ___ 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?
	___ disable $FSJ::Ipc::USE_TIE_?H

    ___ 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

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

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

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

    _x_ Resume use of IPCFileHandle, IPCSocketHandle. The goal is to be
        allowed to say
	        < {$job->{child_stdout}} >
        instead of having to say
                $job->read_stdout()
        to get the blocking and timeout behavior. Then we would change
	all the creepy   ? _read_socket(*STDIN) : <STDIN>)  constructions
	in t/43* and t/44* to    <STDIN> , and the user would not have
	to know whether he was using F::S and whether F::S was using 
	sockets.

	_X_ Until we bring pipes into the fold, too, some of the
	    read input constructions are getting creepier (see 44a, 44b)
	    _X_ Meh. This isn't really true. Without tied sockethandles,

	_X_ Outstanding issues:
	    Strawberry 43d, 44d sometimes time out
	    Performance? Is NO_TIES=1 version of some tests faster?

    ___ Forks::Super::Job can overload "<>" (iteration) operator,
	invoking $job->read_stdout(). Beware of overload bug, though:
	"Even in list context, the iterator is currently called only
	once and with scalar context."

    ___ test suspend/resume cycles where child has SIGSTOP/CONT handlers

    _x_ "Don't exit from child sub with socket IPC" -- can we address this?
	A child-specific END{} block in Forks/Super/Job.pm ?

    _X_ Forks::Super::Sigchld notes in a comment that dates back to v0.16
        that Cygwin might not clean up deferred jobs correctly. Is this
	still an issue? Doesn't look like it ...

    _X_ 40d problem on solaris
	___ will we ever use setitimer for timeout/expiration?

    ___ Understand why Windows hack needed for socket write (see 
	FSJ::Ipc::write_stdin, FST::IPCSocketHandle::trivial_pause).
	Is there a better solution?

    ___ Upgrade bundles Sys::CpuAffinity to 1.00.

    _X_ dir => directory  option to run the child process from
	a particular directory.
	Child dies if not able to change to the specificed directory.

    _X_ allow cpu_affinity => [ @list ] style
