JeffGarland / liaw2019-process

Repository for initial drafting of boost.process standards paper
MIT License
5 stars 4 forks source link

Roadmap #30

Open klemens-morgenstern opened 5 years ago

klemens-morgenstern commented 5 years ago

Just to have it in one place, the question is what phases we want to have in the evolution of the paper. Based on the assumption that we want to do async late, I put that together - we could also keep the async in from phase 1.

  1. std::process with launcher/Initializer, without async but a simple env initializer (from char**), std::process_io, std::process_start_dir
  2. std::process_group
  3. std::this_process without environment
  4. std::environment && std::this_process::environment
  5. std::pstream (std::pstreambuf)
  6. async_wait for std::process & std::process_group
  7. std::pipe_end & std::pipe (the async ones)

As an alternative, I think we could split the paper up into three separate ones:

  1. Process
  2. Pipes
  3. Environment

Pipes & Processes are often mentioned together, BUT there is not reason they need to be – I can use processes without pipes and I can use pipes for inter-thread communication. If we consider this code:

auto [p_in, p_out] = std::pstream(); std::process proc("foo", {}, std::process_io(p_out, {}, {}));

The only actual interaction we have between the pipe and thre process library is that std::process_io accepts and argument of type std::pstream. Now, the same is (or at least should be) true for std::fstream.

The same goes for the environment:

std::environment env = std::this_process::environment(); std::process proc("foo"; {}, env);

The only interaction (besides the namespace this_process is that environment implements the concept ProcessInitializer.

So the actual overlap in terms of specification is actually rather small. Now, please note that we have one async function in the process, namely async_wait.