[Note] process_group is easy

[klemens-morgenstern]

I implemented a process_group (which we removed from the proposal) on posix & windows with the following API for the reference implementaiton.

struct process_group
{

    typedef ... native_handle_type;
    native_handle_type native_handle() const { return _group.native_handle(); }

    process_group() = default;
    explicit process_group(native_handle_type handle);
    process_group(const process_group &) = delete;
    process_group(process_group && ) = default;

    process_group &operator=(const process_group &) = delete;
    process_group &operator=(process_group && ) = default;

    template<detail::process_initializer<default_process_launcher>  ... Inits>
    pid_type emplace(const std::filesystem::path& exe, std::initializer_list<std::wstring_view> args, Inits&&... inits);

    // Construct a child from a property list and launch it with a custom process launcher
    template<process_launcher Launcher, detail::process_initializer<Launcher> ... Inits>
    pid_type emplace(const std::filesystem::path& exe,
                     std::initializer_list<std::wstring_view> args,
                     Inits&&... inits,
                     Launcher&& launcher);

    // Construct a child from a property list and launch it.
    template<detail::process_initializer<default_process_launcher>  ... Inits>
    pid_type emplace(const std::filesystem::path& exe, std::initializer_list<std::string_view> args, Inits&&... inits);

    // Construct a child from a property list and launch it with a custom process launcher
    template<process_launcher Launcher, detail::process_initializer<Launcher> ... Inits>
    pid_type emplace(const std::filesystem::path& exe,
                     std::initializer_list<std::string_view> args,
                     Inits&&... inits,
                     Launcher&& launcher);

    // Construct a child from a property list and launch it.
    template<typename Args, detail::process_initializer<default_process_launcher>  ... Inits>
    pid_type emplace(const std::filesystem::path& exe, Args&& args, Inits&&... inits);

    // Construct a child from a property list and launch it with a custom process launcher
    template<process_launcher Launcher, typename Args,
            detail::process_initializer<Launcher> ... Inits>
    pid_type emplace(const std::filesystem::path& exe,
                     Args&& args,
                     Inits&&... inits,
                     Launcher&& launcher);

    pid_type attach(process && proc);
    bool contains(pid_type proc);

    void terminate();

    void wait();
    pid_type wait_one();
};

The implementation is rather easy, the only thing I have not done is the async_wait since this would require a new IO object for asio. I don't want to spend too much time on that, since this was just a PoC for me.

TLDR: process_group is easy enough, but I do see why it does not need to be part of the core proposal.

Note: The process.pdf does contain this class, p1750r1.pdf not.

[klemens-morgenstern]

@JeffGarland I hope you don't me using the issues as my personal notebook for the ref implementation. That seems to be the easiest way to keep that visible for everyone.

[JeffGarland]

@klemens-morgenstern No problem at all on issues -- it's very helpful. My recollection of process_group removal request was simply one of trying to simplify the proposal knowing that it could be added later. The standard can never do everything so you're always going to have 'boost' and other library additions in the eco system that build on std. And the thinking, at the time at least, was that getting the core of process was the most important near term effort so we should focus on that.