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
	_X_ tightened some delays in file-based IPC

    ___ 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
	___ I/O layers? :gz? :crlf?

    ___ 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.
    ___ No complaints yet, but is there a smarter way to
        set the IPC directory?

    ___ 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
	    _X_ factorial.pl for bg_eval
        ___ 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.
	_o_ 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.

    _o_ Fails t/20 t/21 on OpenBSD run as make test, but succeed as
	standalone? What's up with that? process groups?
	Intermittent failures -- probably max background process
	restrictions on my OpenBSD host.

    _X_ 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."
	___ Actually, maybe it can't. Can't define even the buggy
            version of Forks::Super::Job::(<> except with some
	    crazy machinations.

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

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

    ___ umask => 0123 option?

    _X_ allow cpu_affinity => [ @list ] style

    ___ 0.51 test failures. I don't think any of these are
        reliably reproducible
	_x_ timeout takes 10000s in FreeBSD
	    suppress return from SIGALRM handler
	_x_ 25#15-17 on loaded Linux 5.14.0
	    wait longer for child feedback
	_o_ 40i#2 problem on Linux (x3)
	    was elapsed time too high (>7s) or too low (<4s)? Can't tell.
	_x_ 42g#17-18 on loaded Linux 5.14.0
	    wait longer to receive STDOUT
	___ 43d exit 13 on Linux (SIGPIPE)
	_o_ 44a#7-12 on MSWin32
	___ 24 exit 2 on MSWin32 (SIGINT),
	    47 exit 15 on MSWin32 (SIGTERM),
	    48 exit 23 on MSWin32 (SIGSTOP)
	___ 49#4 on Linux
	___ 49#5,8 on MSWin32
	_o_ 54#10 on Linux
	___ break 49 up?

    ___ Does anything bad happen when you set $SIG{CHLD} = 'IGNORE' ?

    ___ Prior to v0.52, bg_eval and bg_qx could be called in list context
        but they wouldn't return control to foreground process. Can this
	be fixed?

    ___ is _trap_signals call in FSJ::Ipc::_config_fh_parent necessary?

    _X_ FSJ::Ipc::_close, _close_socket: no warnings pragmas are too strong.
        _o_ untie attempted while 2 inner refs exist ... 2065 [untie]
	_X_ use of uninit value in numeric ge (>=)  2084 [uninitialized]
        _X_ use of uninit value in bitwise and (&)  2087 [uninitialized]

    ___ $F::S::CHILD_FORK_OK>0 -- not tested ...

    ___ Implement, test respect block/timeout in IPCPipeHandle

    ___ Track down, solve 'untie attempted while ... inner references'
        mystery with FST::IPCFileHandle
