any tricks to make SHELL non blocking?

[Paul Dupuis]

On 2/2/2018 5:42 PM, Richard Gaskin via use-livecode wrote:
> Paul Dupuis wrote:
>
> > I don't think you can use shell as non-blocking. You could use 'open
> > process' to spawn your command line utility off as a subprocess which
> > would be non blocking, but that approach has its own over head thing
> > to work around
>
> What additional overhead is incurred by running a process via "open
> process" vs the shell function?
>
Correction, I wasn't speaking of 'overhead' as CPU overhead, but as
other things you may need to do as a developer. For example, shell()
nicely runs the app specified and returns any return value, where as
with 'open process' you need to also read from the process to get
returned data, close the process. Any helper app you install that you
call via open process (i.e. some app that is not already part of the OS
or installed software), you really need to code sign (a good practice
anyway) otherwise, assorted 3rd party security tools (mostly on Windows
like McAfee or Norton) are likely to interfere with your launching of
the app via open process by treating it as suspicious activity.

There are probably a few other detail I have forgotten as I wrote this.
We just went through this for a couple of HyperRESEARCH (our app) helper
apps (also LC standalones) that 4.0 of HyperRESEARCH communicates with.

FYI we found that interapp communication via sockets is more reliable
cross-platform that via interprocess communication, but at some real
world customer sites, security setting can prohibit socket communication
even to the same computer where as IPC still works, so an app that need
to be really really robust for real world installs may wish to include
code for both and swap from one to the other if one means of
communication fails.

-- Paul