Does reproc provide the PID of the process opened?
I need a way to open an application (in a window, or the background) and close it at a later time (possibly a long time). The framework I am working within will only allow me to pass strings, or numbers between its contexts, and the context may change before I need to close the process.
I have done this all with WINDOWS calls and it works well, but I need to make a Mac friendly version. To ensure that the process I close is in fact the same one I opened, I lookedup the window PID, and compared its executable path (also passed between contexts).
I need a way to open an application (in a window, or the background) and close it at a later time (possibly a long time). The framework I am working within will only allow me to pass strings, or numbers between its contexts, and the context may change before I need to close the process.
I have done this all with WINDOWS calls and it works well, but I need to make a Mac friendly version. To ensure that the process I close is in fact the same one I opened, I lookedup the window PID, and compared its executable path (also passed between contexts).
However, with just the pid you won't be able to use reproc to close the process (you need the entire
reproc_typestruct)
Is passing a pointer to a
reproc_type struct between contexts out of the question?
Another problem I see with that approach is that by only closing the process handle the pipe handles used by reproc won't be closed correctly which would result in resource leaks
Is it required to open the Pipe handles? I dont need them.
I simply need to be able to open an executable, track it (PID, filepath) and close it. No additional communications needed.
As for having some platform specific code.. if I must. Of course I am looking to make adding the feature to multiple platforms as easy/maintainable as possible.
I simply need to be able to open an executable, track it (PID, filepath) and close it. No additional communications needed.
As for having some platform specific code.. if I must. Of course I am looking to make adding the feature to multiple platforms as easy/maintainable as possible.
From what I can see, right now reproc doesn't support your use case. To support it we'd have to make redirecting the standard streams of child processes optional, support retrieving the pid of started processes and allow closing of arbitrary pid's. Unfortunately, that's quite a bit of API surface (especially closing arbitrary pid's) to add for a very specific use case. I'd very much prefer to keep reproc's API as small as possible.
Is the framework you use open source?
I'm building personal plugins for Isadora (a visual programming environment for art). I am working mostly with external executables I have created in OpenFrameWorks (open source c++ creative coding framework), I plan on making my plugin code opensource, but Isadora is not.
Thanks for all the feedback.. I have zero experience with coding on Mac or Linux, so the difference in how processes are handled is all new to me.
I might have a solution although its a bit hacky
After a process is started using
reproc_start the reproc_type struct stores all the necessary information for further calls to reproc.
You might be able to send all the fields separately between contexts and reconstruct the
reproc_type struct manually in the new context and call reproc's function for stopping a process.
The transferring code would be platform specific since the
reproc_type struct contains different information depending on the platform but the rest of the code would still be cross platform.
I was playing with Intel's PrallelSTL and in about 5 minutes got to the point where
std::sort of 65k elements works as fast as std::partial_sort of 10 (out of 65k total) elements.
no idea what was going on there
distributing might not be the right word
Although CMake config files are a contender as well with meson adding support for them
At some point the cumulative needs of the users will make you wish you had a turing complete language instead of ad-hoc solutions in the "it's good enough" declarative language.