As Michel said, in windows a shell is not a child.
More than 10 years ago I developped such a setup for windows where I had to use VB6. No threading at all.
I defined a Taskmanagwr In the middle which was small and dedicated and usimg IP sockets to communicate which activeX exe stubs. After all this taskmanager was able to kill theae processes if they might not disappear on tear down. This project is still running in unattended production.
I’ve been looking into this also, as we use helper apps. I was going to investigate IPC and attempt to create a framework (especially as I want to pass complex data, maybe even bitmap images).
As for quitting the helper application, personally I would make the main application issue a quit command first or on the helper in the event of an IPC disconnect, for it to quit.
Shell also has the limitation that it cannot interact with Sandboxed helper applications and to ship on the App Store, helper applications should be Sandboxed.
For what it’s worth, I have Apps launching tons of async Shells/Helpers.
I do queuing based on available resources so they launch as much Helpers as possible. I sometimes see 500+ Helpers active and all works smooth, fast and no problems whatsoever.
Most of them are small and done in <100ms. Others are take longer and do stuff like video processing.
I tried to do things with IPC but could only make it work small scale. Maybe I haven’t put enough time into it but I currently launch each Helper with either arguments or reference to a command (.json) file in temp/session folder so it knows what to do.
If the helpers need additional files or data, I drop those in the session folder as well and clean things up afterwards.
To do all this, I’ve made a little class that manages an array of Shells. It passes tags around as reference that I use to identify the task in the Completed event. From there, I forward the results to the appropriate method.
Many Helpers Shell out to other things (ffmpeg, curl, system commands etc.). In OS X, this works great because if the parent is killed, all childs go away. In Windows this is a pita and I hope to find a solution for that one day.
I use the standard Xojo Shell. In the past, I’ve put weeks into getting async(!) NSTask’s to work properly but I gave up. I got very strange results and things were very unstable. Especially with rapid firing of new tasks I got things like incorrect Pids or it said the tasks were running while they weren’t. I concluded that I’m not smart enough to make it work.
It frustrates me because I think that NSTask should be the underlying Xojo Shell -mechanism in the first place.
Maybe it’s an official rule (or maybe I don’t know what you mean) but I understand that Apps that use the Xojo Shell pass screening without problems and work fine as long as the Helpers were included in the bundle.
Officially each executable within the application bundle should be Sandboxed with at least the inheritance entitlement. The trouble is when this happens, the executable can no longer be called from a Xojo shell.
NSTask is cumbersome and integrating it with Xojo is a PITA, especially since Apple moved to blocks and some of those re-enter on a different thread.
I’ve helped quite a few developers who’ve not been to able to submit their application because of this requirement, I guess the others who are allowed don’t contact me as they can get through by themselves.
Theres a feature request for Xojo to use/support NSTask with the shell class. <https://xojo.com/issue/26605>
This is one of the problems I have with the App Store, is the inconsistency. The worst is not being allowed to post a version 2 of an application because we already have a version 1, and yet many of our competitors have version 1, version 2 and version 3 for sale (to which our reviewer doesn’t care). It irks me more when all their versions use the same text & same screenshots.
For a while now, I have been retiring previous versions and creating a brand new app for new versions. It is pity for previous customers who don’t receive updates, but it is good for business, as new applications are pushed up.
I think, if I’m to start this, I will start simply using my original plan. This will follow the basic plan of my REST client classes, i.e., the host app sends a “message” to a helper, then reacts to the response. The helper’s job will be to launch, do its thing, then quit. On Windows, I have to make sure the helper app gets killed if needed.
There was a thread a while ago about the same kind of topic : https://forum.xojo.com/6243-force-quit-a-shell-windows/20
Personally, I use Tasklist to get the app process number and then call TaskKill to have the app cleanly terminate.
For instance tasklist /fi "IMAGENAME eq myapp.exe" willpickup all sessions of myapp and list the PID :
Image Name PID Session Name Session# Mem Usage
========================= ======== ================ =========== ============
myapp.exe 4100 Console 3 12,356 K
taskkill /pid 4100