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. 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