Am 18.07.2016 um 16:12 schrieb Zach Laine:

This submission looks like it's heading very much in the right direction. We really need a standard facility for process launches, and this a Boost lib is a good first step.

Thanks, I'm glad to hear that.

I submitted a PR for a documentation typo, but other than that, I only have one note. From the docs:

"Async pipes use named pipes on windows. Therefore an exception is thrown if a pipe was not constructed as a named pipe and is converted to an async_pipe"

It is widely considered to be bad practice to throw on programmer errors. It sounds like you should be asserting on invalid async_pipe conversions, since the precondition for doing so has not been met. Throwing is for conditions that could not have been fixed at the time the user wrote the code (like a failed parse of something read off a wire, for instance).

Ok, I'll have to think about that. The problem is: you can construct a pipe with a name, making it usable with async_pipe, i.e.: pipe p; async_pipe ap(p); //exception. pipe p(".\\\\pipe\\some_pipe"); async_pipe ap(p); And if you have a function which expects a pipe, it may not be visible which sort of pipe is passed, so it ought to be handles at runtime.

On Fri, Aug 5, 2016 at 4:02 PM Joseph Van Riper wrote:

A small typo: on http://klemens-morgenstern.github.io/process/boost_process/tutorial.html, 'differenc' instead of 'different'.

I haven't looked through all of the documentation yet, but that stood out for me.

And immediately after sending that, I saw the following on the same page: Alterantively instead of Alternatively. higly instead of highly. I hope this helps. - Trey

Am 06.08.2016 um 03:21 schrieb Joseph Van Riper:

On Mon, Jul 18, 2016 at 9:41 AM Klemens Morgenstern < klemens.morgenstern@gmx.net> wrote:

...

Hi,

boost-process is now in beta, you can check it out here: https://github.com/klemens-morgenstern/boost-process

and read the doc here: http://klemens-morgenstern.github.io/process/

It will probably be in review in the beginning of November, Antony Polukhin will be the review manager. I really hope I'll get some feedback before that, so I can work on the weak points and also get more detailed in the documentation.

I tried at least part of the tutorial on an Ubuntu 16 machine using the git cloned code you have made available as of today, and I have the following observations:

- Your example code suggests you look through a path of some kind for the executable, but while trying the code on my own, it did not seem to do this. I had to use absolute paths to the executable I wanted to run. Which is okay, but it feels like the docs need to manage my expectations a bit better there.

First of all, thank you very much for trying it out. That question is noted for the FAQ. No, it does not look into the path, but the system might do that. If you want to search PATH, you can use boost::process::search_path.

- Your documentation suggests the executable I'd create would terminate when the child it spawned ends. I do not see this... my executable hangs indefinitely. 'while (c.running() && std::getline(is, line)) data.push_back(line);' never ends for me. Is this a bug you are currently working through, or is there something else that the tutorial may have missed?

The exiting child does NOT close the pipe. So I guess you'd be hanging in std::getline(is, line), not in c.running(). If I'm wrong about this one, please tell me. We had this issue now a few times, where people expected the pipe to close. Problem is: that cannot be done for all cases, hence it is not implemented that way.

- Your documentation doesn't tell me much about boost dependencies. I originally tried to work with the boost library one may apt install for Ubuntu 16, but it didn't seem your library was compatible with it (or maybe I erred somehow). I pulled down boost 1.61 and it compiled with that just fine, but I wonder what is the oldest boost library one may use? If there's a limit, it probably ought to be mentioned in the documentation, since many distributions are terrible about keeping up with the most current boost distribution. Actually, that would be the develop-branch of boost, i.e. 1.62. You can currently only use the current version, since I also updated boost.winapi. That wouldn't concern you on ubuntu, but that's the actual dependency.

- Trey

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Am 06.08.2016 um 22:55 schrieb Joseph Van Riper:

On Fri, Aug 5, 2016 at 9:38 PM Klemens Morgenstern < klemens.morgenstern@gmx.net> wrote:

...

Am 06.08.2016 um 03:21 schrieb Joseph Van Riper:

...

On Mon, Jul 18, 2016 at 9:41 AM Klemens Morgenstern < klemens.morgenstern@gmx.net> wrote: - Your example code suggests you look through a path of some kind for the executable, but while trying the code on my own, it did not seem to do this. I had to use absolute paths to the executable I wanted to run. Which is okay, but it feels like the docs need to manage my expectations a bit better there.

First of all, thank you very much for trying it out. That question is noted for the FAQ. No, it does not look into the path, but the system might do that. If you want to search PATH, you can use boost::process::search_path.

Glad to help. I'd really like to see this adopted. I needed this recently, and wound up using the old one from 2012 that boost turned down. I fully understand (having been forced to use it) why it was turned down, and had to make some silly adjustments of my own to make it do what I needed. This is a far cleaner approach, I feel.

...

- Your documentation suggests the executable I'd create would terminate

...

when the child it spawned ends. I do not see this... my executable hangs indefinitely. 'while (c.running() && std::getline(is, line)) data.push_back(line);' never ends for me. Is this a bug you are currently working through, or is there something else that the tutorial may have missed?

The exiting child does NOT close the pipe. So I guess you'd be hanging in std::getline(is, line), not in c.running(). If I'm wrong about this one, please tell me. We had this issue now a few times, where people expected the pipe to close. Problem is: that cannot be done for all cases, hence it is not implemented that way.

Well, this is an issue of managing expectations within your own tutorial. Your own tutorial expects that while loop to finish. I did not write that code. Although I'll admit that I have a tendency to expect whatever a tutorial expects, heh. So, if the tutorial is not matching expectations, perhaps it needs some adjustment.

Untested code in the tutorial rather. Bad anyway.

As for where it's hanging, I can't be sure. I'm actually a Windows developer who finds himself writing a lot of cross-platform code between Linux and Windows, which is one of the reasons I'd love to see this working well, heh.

I tried debugging this, but gdb is kind of a funny debugger with a million special options that become exposed in special ways when you get into forking and multiprocessing. The code worked perfectly well in gdb, but hangs when executed directly. Which offers some kind of hint as to what is happening, but I lack experience with gdb to drill into what.

At a guess, knowing a little bit about gdb and multithreading, when a thread spawns, it follows the new thread (I think), leaving the parent thread to go on its way. As I was stepping through instructions, the parent thread probably got ahead of the child and finished something it was supposed to finish, I suspect, making it possible for the child to avoid hanging somewhere.

At least, that is my semi-educated guess on this.

I could maybe try adding a touch of logging so I don't need a debugger to see what is happening, but I would have to dig significantly into the code... I'll have to find time for that kind of effort.

It seems to be a race condition - i.e. depending on wether there's a line left in the buffer and when the program exits. I'll need to write another example there. It's probably never smart to write a while loop in this case. Btw: i recommend to use the asio functionality, that works much better. I'm already using that myself, did not run into any problems.

...

Actually, that would be the develop-branch of boost, i.e. 1.62. You can currently only use the current version, since I also updated boost.winapi. That wouldn't concern you on ubuntu, but that's the actual dependency.

Oh.. interesting. I guess if this library becomes released with 1.62, you wouldn't have to mention the minimum required boost distribution. That makes sense.

- Trey

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Am 07.08.2016 um 13:08 schrieb Antony Polukhin:

...

Btw: i recommend to use the asio functionality, that works much better. I'm already using that myself, did not run into any problems.

I'd like to have a non ASIO version working out of the box. ASIO is an overkill in such simple cases.

Well, it does work out of the box. Problem is: the pipe is not closed automatically, so you might get a deadlock if you're trying to read after the program has exited. Reason is: on posix you can set a flag to close a pipe when the child exits. On windows you cannot, you'd have to close the sink on the launching process so that only the launched process has a handle to it. BUT, when I use an named pipe it is essentially a file-handle. With that, it does not work at all. So in order to keep this consistent, the pipe will not be closed on child exit. That can cause a deadlock Now if you know how the output looks, you can use it. If you don't, well, you'll probably get a deadlock. In the case of the example: 'nm ' appends an empty line at the end, so I'd need to check for that, i.e.: while (c.running() && std::getline(is, line) && (line.size() > 0)) {...} I'll fix the documentation soon.