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 _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
