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

Subject: Re: [boost] [boost-process] Beta & Review
From: Joseph Van Riper (fleeb.fantastique_at_[hidden])
Date: 2016-08-06 16:55:39

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.

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.

> 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