Introduce <process> to manage processes

[david.b...@gmail.com]

Since we have <thread> interface to work with threads since C++11, it would be useful to wrap also the process managment (Unix, Windows) into <process>. The goal is to create and communicate with processes as similar to std::thread as possible.

* Create new process

* Wait for process (by pid, group, like waitpid)

* Exit process

* Get status of the process/its exit status

* List all process

* Your ideas?

[Alexander Zaitsev]

Do you know about Boost.Process?

пятница, 18 августа 2017 г., 16:30:14 UTC+3 пользователь david.b...@gmail.com написал:

[david.b...@gmail.com]

Yes, I do. 

But still, not everybody wants to use boost (or simply they cannot).

Dňa piatok, 18. augusta 2017 15:32:21 UTC+2 Alexander Zaitsev napísal(-a):

[Alexander Zaitsev]

I think we should test it a lot inside Boost, wait for e.g. Boost 1.70, and after that i hope that Boost.Process will become very-very stable library.

After that we should talk with Boost.Process's author, Klemens D. Morgenstern, and together write good proposal.

пятница, 18 августа 2017 г., 17:03:29 UTC+3 пользователь david.b...@gmail.com написал:

[Thiago Macieira]

Please propose an API. The general idea is good, but the devil will be on the
details. Handling processes is very difficult, starting with the fact that a
process requires a file name, so it rus afoul of the same problems that the
filesystem API did. Then you're going to add the ability to set Windows
security properties, handling of file descriptors inherited (or closed),
environment manipulation, etc.

And finally, like sockets, you get asynchronous events that the application
needs to be told, somehow.

Your proposal should have some mileage on it to prove it's workable.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

[Ryan Nicholl]

I think processes are too OS-specific and should not be included in C++.

[Nicol Bolas]

On Wednesday, August 23, 2017 at 7:30:20 PM UTC-4, Ryan Nicholl wrote:

I think processes are too OS-specific and should not be included in C++.

Like graphics. And networking. And filesystems. And threading. And file access. And `std::system`, from the C runtime library.

Sorry, but the "OS-specific" ship sailed long ago. That's not to say that I agree with this specific proposal (which is not a proposal; it's an idea at best), but your argument against it just doesn't hold water.

[Ryan Nicholl]

At least file systems tend to be fairly consistent between systems. Threading is pretty basic. But process management? That's a new can of worms. How do we deal with differing contexts? Systems where the process doesn't have the authority to generate new processes?
Just because we added filesystem support (a terrible idea, at least the way it was implemented) doesn't mean we need to adopt more terrible ideas.

Although threading has many OS specific aspects, there is enough commonality between threading environments that it usually works out. In order to start a process we'd need an executable, which is very OS-specific by definition. And what happens when we don't have execute permission? Are you suggest we add support for Unix specific file system permissions? And what about windows? It's too complicated to do it in a cross platform way.

[Michał Dominiak]

You don't need a notion of "executable", just a notion of commands. This notion already exists in the standard, to an extend, in the terrible API of std::system. And Boost.Process does it in a nicely cross-platform way (note I did not say "in a nice way"; I'm not commenting on the API, just on its cross-platform-ness).

Now also tell us how having file access API is a terrible idea, because file handle management is a can of worms, because how do we deal with processes with no authority to open files? In order to open a file you'd need a file path, which is very OS-specific by definition. And what happens when we don't have read or write permissions? Are you suggesting we add support for Unix specific file permissions? And what about windows? It's certainly too complicated to do it in a cross platform way.

Oh wait, scratch that. We have a file access API since C++98 and it's been working out pretty well, and we don't need to check permissions when opening a file. That is a std::filesystem issue and I don't want to engage in a discussion about your opinion on it. But again: you don't need a way to check permissions to open a file; simiarly you don't need to check whether you can spawn a process whose command is "X Y Z". You can just assume you can do it and get an error when you try. (By the way - checking and then doing a thing when you checked you have rights is a race condition with the outside world changing your permissions.)

You don't even need to know what an "executable" is if you are just operating on command-line argument lists.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cd06020d-157b-4bda-826b-3aa2c3d59782%40isocpp.org.

[Klaim - Joël Lamotte]

On 25 August 2017 at 00:24, Ryan Nicholl <r.p.n...@gmail.com> wrote:

At least file systems tend to be fairly consistent between systems.

In the last 10 years (so not so long ago, and still are supported) 

I've worked on systems where file systems were so minimal I'm not even sure the standard would have been implemented there.

 

Threading is pretty basic.

There was no way to create threads on these embedded platforms.

 

But process management? That's a new can of worms.

Like the rest.

Also note that it can always be allowed to not be provided on platforms where it make no sense.

The real question is: is it useful to a majority of C++ users.

In a concurrent multi-process world like today, it seem obvious, at least to me, that it is.

So I don't see your point, in the same way I didn't see the point of this argument for thread and filesystem (it was raised each time those boost libraries were considered for standardisation).

 

How do we deal with differing contexts?

Are you talking about what provide Boost.Context?

 

Systems where the process doesn't have the authority to generate new processes?

That's the role of the proposal author to provide way to deal with these situations, if it make sense to support them.

As said, it's always open to specify some part of the behaviour as platform-defined, for example. Or garantee that something

will not compile if the platform don't allow it.

It's already the case when you have static asserts checking for pointer or int size.

 

Just because we added filesystem support (a terrible idea, at least the way it was implemented) doesn't mean we need to adopt more terrible ideas.

I strongly disagree. It solve tons of problems. If you want something more specific, you can always use something else. If you don't, it's available,

like for the majority of cases.

 

Although threading has many OS specific aspects, there is enough commonality between threading environments that it usually works out. In order to start a process we'd need an executable, which is very OS-specific by definition.

It does not have to be defined to be allowed. 

 

And what happens when we don't have execute permission?

Again, depends on what the proposal decide. If you disagree with what the proposal design, you could then point why.

 

Are you suggest we add support for Unix specific file system permissions?

See: http://en.cppreference.com/w/cpp/experimental/fs/perms

 

And what about windows? It's too complicated to do it in a cross platform way.

There are ways to get at least the common set of behaviours.

 

On Wednesday, August 23, 2017 at 8:34:55 PM UTC-4, Nicol Bolas wrote:

On Wednesday, August 23, 2017 at 7:30:20 PM UTC-4, Ryan Nicholl wrote:

I think processes are too OS-specific and should not be included in C++.

Like graphics. And networking. And filesystems. And threading. And file access. And `std::system`, from the C runtime library.

Sorry, but the "OS-specific" ship sailed long ago. That's not to say that I agree with this specific proposal (which is not a proposal; it's an idea at best), but your argument against it just doesn't hold water.

--

You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.

To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.

To post to this group, send email to std-pr...@isocpp.org.

[Thiago Macieira]

On Thursday, 24 August 2017 15:47:37 PDT Klaim - Joël Lamotte wrote:
> > Threading is pretty basic.
>
> There was no way to create threads on these embedded platforms.

I remember when *Linux* did not have support for threading. Anyone else old
enough to remember libc5 and glibc 2.0? Threading came in 2.1, which was less
than 20 years ago.