I have a console app (not written by me and not written in Xojo) that I need to use in my Xojo desktop app. The console app is copied into my app’s package (/Contents/MacOS/Library/Helpers) by a build script.
The console app takes a file, parses it and outputs XML to stdout. Currently my app takes a reference to the file and calls the console app via a Shell then reads the XML from Shell.Result. It uses the XML to construct an instance of a class. This works but I want to make sure I’m using Shell appropriately.
I’m using Shell in Synchronous mode. I understand that this blocks the main thread but I’m not clear on the difference between Asynchronous and Interactive modes. I don’t need to “interact” with the console app after I’ve passed it the file to parse other than to get the contents of stdout.
Would using a Worker offer me any advantage other than using Shell? I understand that Workers get compiled into their own console apps but since the Worker would need to call a bundled console app itself would this negate any speed / performance benefit?
I’m trying to make sure I maximise he multicore nature of the systems I’m targeting.
Doesn’t allow you to communicate using .Write and .WriteLine
Does allow you to communicate using .Write and .WriteLine
Both work Async wit the .DataAvailable event on data and .Completed when the console app closes.
In a worker you could manage the shell and console app development and comms using your desktop project, making it much faster to develop. But it comes at a cost, that is it’s harder to re-use the worker since it’s only available on Desktop projects, you can’t use it in WebApplications, Console, iOS etc.
An alternative to a Worker is for example a Array of Shell classes (Asynchronous or Interactive) that are kept running until they are done.
A Worker is for when you need to do the work yourself outside your main app.
In your case, I’d use a Shell in Asynchronous mode since the console app will be doing all the work. Call it, then wait for the result in the event as Derk described. You’ll get the benefit of a Worker without the additional effort to set up the Worker.
Presumably this matters because the console app takes some significant amount of time?
Yep, the console app takes a variable amount of time but can be upwards of 100ms. It’s also probable that I need to parse several files in quick succession so being able to do 8-10 at a time on a multi core CPU would be a good performance boost.
NO. this “multithread functionality” in xojo is fake, just marketing launching a helper app and calling that multicore. In this case you already have the helpper app, adding an extra helpper to call the helpper will add the overhead of launching it each time plus harder to manage.
Try to create a bunch of Asynchronous Shells in a window for example to not losee the scope and use the events to read the results and send the next file