Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support non-blocking calls #9

Open
rajatjain1997 opened this issue Sep 12, 2021 · 3 comments
Open

Support non-blocking calls #9

rajatjain1997 opened this issue Sep 12, 2021 · 3 comments

Comments

@rajatjain1997
Copy link
Owner

No description provided.

@shawnw
Copy link
Contributor

shawnw commented Sep 12, 2021

(Continued from reddit)

For asynchronous command execution, there's two scenarios to consider.

First, running a command in the background with one or more of its stdin/stdout/stderr connected to an iostream. Might be worth looking into Boost.Process's pipe streams and buffers as an example of a fairly lightweight way to provide such streams. You still need a way to get a command's exit status when it finishes running (Just getting EOF on a pipe isn't enough).

Second, the case where you just want to capture the output in a string. My idea for this (Which can also be used for the exit status of the first case and possibly even in executing pipelines of multiple commands) is to have a run_async() method that returns a future that, when complete, gives you an object with the captured stdout/stderr (If any), exit status, etc.

It'd look something like

std::future<result> status = command.run_async();
while (status.wait_for(std::chrono::seconds::zero) != std::future::ready) {
    // Do something else
}
auto res = status.get();
std::cout << res.stdout() << '\n';

@mavam
Copy link

mavam commented Sep 13, 2021

As you are designing the async API, here are a few thoughts that came up:

  1. Long-running pipes will delay the final result and in realtime applications, users are often interested in processing chunks of data as they flow in. It would be nice to have something like a span<const byte> or string_view abstraction to process data as it arrives, e.g., in 64k blocks.
  2. From a dependency perspective, a hard requirement on Boost would rule us out as user. If you go down the Boost.Process route, it would be great to keep it optional.

@shawnw
Copy link
Contributor

shawnw commented Sep 15, 2021

Work in progress at https://github.com/shawnw/subprocess/tree/async_promises

(At the moment just uses futures for waiting for processes to exit in command::run().

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants