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