Using fork/exec/wait on macOS

I’m writing a REST service that will run on macOS exclusively. It currently accepts the various requests from clients, is manageable from a remote GUI app, etc. The fundamentals of the server are working as designed.

The core functionality of this server is a structural frame analysis. For now, the client is sending N number of frames (N=30 for example) to the server for analysis. The server is analyzing these N number of frames one at a time, then returning the results in a large JSON response. This all works well, except that it’s a sequential process and the time required is approximately N*1.8 seconds.

I wish to “parallelize” this a bit and have the server fork/exec/wait an individual child analysis process for each of the N frames in the client request. This way, if the server is running on high core count machine the additional cores are being leveraged. So my question becomes, does XOJO have a workable fork/wait functionality already in place, or do I need to create wrapper functions in Xcode and use Declares?

I am familiar with the Shell.mode = 1 for asynchronous work, but this requires the overhead of launching bash, and it seems that I’ve heard there is a limit on the number of shells that can be active at any one time. But I may be wrong on that point.

Any advice or experience on the topic would be greatly appreciated.

How many shells are you talking about? I’ve launched 24 shell processes using Xojo on a 32 core Z840 with no issues (granted, under Linux).

Thanks Tim for the reply.

The maximum number has no particular upper limit. It wouldn’t surprise me to see a single client request queue up several dozen frames for analysis. I suppose I could write out a single bash script that runs the N number of jobs in the background, each with its own stdin/stdout file, and then does its own ‘wait’ command before returning the Xojo code. But that starts getting a bit nasty with with lots of temporary disk files. I was just hoping for something a bit leaner and cleaner.

In that case, I don’t see an issue with using Shell objects since you really don’t want to exec more than 1 less than the number of supported threads for best performance.