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

[Note] process_group is easy #61

Open
klemens-morgenstern opened this issue Oct 12, 2020 · 2 comments
Open

[Note] process_group is easy #61

klemens-morgenstern opened this issue Oct 12, 2020 · 2 comments

Comments

@klemens-morgenstern
Copy link
Contributor

klemens-morgenstern commented Oct 12, 2020

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
Copy link
Contributor Author

@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
Copy link
Owner

@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.

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

2 participants