[PD] Seeking feedback on batch mode manager

[Charles Z Henry]

Hi list,

I've reached a stopping point on a batch mode manager with communication.
https://github.com/czhenry/czbs

Using ggee/shell, I start "-batch" processes or for editing
"-noaudio".  Those processes can read from shmemID's that the toplevel
process may have set values.  They can also write back values to
shmemID's that the toplevel process polls.

My objective is to be able to run a realtime thread and offload some
processing periodically to another thread.  I had experimented with
using "-batch" as flag with pd~, but my conversations with Christof
showed me I didn't understand it at all.  I was aware of shell, but
I'm leery of having much disk access.  A good solution should cause as
little risk to the realtime process as possible.  I was looking for a
way to keep things around in memory and sending easy to read
instructions to a batch process.

I added signal handler objects that are put in the batch process.  The
2 important ones:
[sigcont] - outputs a bang when pd receives SIGCONT, resumes process
[raisestop] - suspends the current process

They're about the shortest externals you've ever seen--It's remarkable
I get something for so little effort.  So, on load, I have my patch
read from an shmemID to decide whether to continue running, or do
handshake with the parent process to negotiate unique shmemID's for
communication.

After the handshake, the process sleeps and when it receives CONT,
checks for message length in an shmem of length 1, and then reads the
full data from a second shmemID.  Since it's a stream of numbers, I
can make use of FUDI.

I'm pleased that it works, but haven't settled on what the interface
ought to include or what other design issues there are.

The abstractions that do the communication are:
batchmgmt-top.pd  and
batchmgmt-sub.pd

The included test patches are just loopback test patches that shows
two batch processes sending and receiving lists.  I'll work my way up
to audio in a few weeks

I have also included [sigtstp] a SIGTSTP handler that would allow you
to patch commands to run before [raisestop] suspends the process, but
it's not clear if anything's working.

I made use of a wrapper script from a previous pd list thread and
added a wait on the process.  The syntax is a mystery to me.  It was
formed from some amount of stack overflow mimicry and error.  The
batch process stdout is being displayed in the parent process instead
of being routed to [shell]'s output.  Not a big deal, but it's another
potential source of communication that's already provided through
[shell]

It seems I'm just using shell and the wrapper script to monitor the
process.  Is there something I don't know about pd watchdog and
whether/how to sidestep it?

Best,
Chuck