Using fork/exec/wait on macOS

  1. 5 months ago

    E B

    Feb 5 Pre-Release Testers, Xojo Pro Columbus, Mississippi

    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.

  2. Tim J

    Feb 5 Pre-Release Testers, Xojo Pro Dehydrating in AZ

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

  3. E B

    Feb 5 Pre-Release Testers, Xojo Pro Columbus, Mississippi

    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.

  4. Tim J

    Feb 6 Pre-Release Testers, Xojo Pro Dehydrating in AZ

    @E BSanford It wouldn't surprise me to see a single client request queue up several dozen frames for analysis.

    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.

or Sign Up to reply!