Boost logo

Boost :

Subject: Re: [boost] [boost-process] Beta & Review
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-08-06 20:48:38

Am 06.08.2016 um 22:55 schrieb Joseph Van Riper:
> On Fri, Aug 5, 2016 at 9:38 PM Klemens Morgenstern <
> klemens.morgenstern_at_[hidden]> 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_at_[hidden]> 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:

Boost list run by bdawes at, gregod at, cpdaniel at, john at