Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Daan De Meyer
    @DaanDeMeyer
    To avoid blocking the main thread, you can read from the process in a separate thread. The background example gives an example on how this can be done.
    Etorth
    @etorth
    thanks for it!
    Ryan Webber
    @rwebber
    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).
    Daan De Meyer
    @DaanDeMeyer
    I don't think there's a major blocker that prevents us from adding a way to get the process pid to the API.
    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?
    Ryan Webber
    @rwebber
    Yes, my approach on windows was to look at all open windows, to find a matching PID and then check that the filepath of the process matched my original path. Then get the handle and close it. A few steps but it proved to be very reliable for my purposes.
    Daan De Meyer
    @DaanDeMeyer
    So if I understand correctly, you're fine with some platform specific code to close the processes (by matching the pid's) but you still want to use reproc for the rest of the process code?
    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
    Ryan Webber
    @rwebber
    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.
    Daan De Meyer
    @DaanDeMeyer
    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?
    Ryan Webber
    @rwebber
    Thats cool, thats why i'm asking.
    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.
    Daan De Meyer
    @DaanDeMeyer
    The process stuff on MacOS/Linux is definitely not as straightforward as it is on Windows
    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.
    image.png
    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.
    Daan De Meyer
    @DaanDeMeyer
    This does assume stuff like handles and open file descriptors are shared between contexts
    Daan De Meyer
    @DaanDeMeyer
    and that you can send a handle pointer as a number between contexts
    Boris Staletic
    @bstaletic
    I'm going to go offtopic again. Considering there was no talk here since the end of january, I'm guessing that's not so much of a problem.
    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.
    Daan De Meyer
    @DaanDeMeyer
    I'm assuming that's impressive?
    Boris Staletic
    @bstaletic
    The complete std::sort has, considering O(nLogn), has ~5 times more work, but it gets completed in about the same wall time. I do think it's impressive.
    Daan De Meyer
    @DaanDeMeyer
    @bstaletic Thanks for the mention in the Belfast trip report post.
    Boris Staletic
    @bstaletic
    Don't mention it. My first thought was "What trip report? I wasn't in Belfast!"
    Daan De Meyer
    @DaanDeMeyer
    I randomly checked the Traffic report on Github and noticed people were visiting reproc from the belfast trip report post. Never expected that to be the origin of visits
    us-army-uses-reproc.jpg
    Boris Staletic
    @bstaletic
    Hahhaah
    Daan De Meyer
    @DaanDeMeyer
    I had one referal from the US army bugzilla once
    no idea what was going on there
    Boris Staletic
    @bstaletic
    I rewrote that comment a bunch of times, trying to find the right balance between unimportant historical details and details that actually matter.
    Daan De Meyer
    @DaanDeMeyer
    I was a bit dissapointed by ned14's reply to your comment that the API was easy to get right after all the effort I put in keeping reproc's API as simple as possible
    Boris Staletic
    @bstaletic
    I believe what he wanted to say is that it's a much bigger problem being able to change the definition of the abstract machine to make it recognize that the world isn't just the single process that is currently being executed.
    Daan De Meyer
    @DaanDeMeyer
    I agree that's likely a much harder problem to solve. I'm not entirely sure it's worth it to standardize a process library for C++ though. I wouldn't be able to live without subprocess in Python but I feel there's more important stuff to focus on for C++.
    Boris Staletic
    @bstaletic
    I'd much rather see std::process than std::audio, std::video or, god forbid, std::web_view.
    Daan De Meyer
    @DaanDeMeyer
    Naturally, those are much better served by libraries (although a standardized way of distributing libraries might help)
    distributing might not be the right word
    Boris Staletic
    @bstaletic
    Something like cargo/crates.io?
    Daan De Meyer
    @DaanDeMeyer
    More like something that allows interop between all the build systems
    Boris Staletic
    @bstaletic
    May I just say... pkgconfig?
    Daan De Meyer
    @DaanDeMeyer
    It's the closest we have at the moment
    Although CMake config files are a contender as well with meson adding support for them
    Boris Staletic
    @bstaletic
    C++ committee did form a tooling study group.
    Daan De Meyer
    @DaanDeMeyer
    But if something was ever standardized it would very likely be something declarative instead of CMake config files which are imperative
    Boris Staletic
    @bstaletic
    I dislike declarative configuration with passion.
    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.