Re: [boost] [boost-process] Beta & Review

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: http://lists.boost.org/mailman/listinfo.cgi/boost
>