1

When I run this code, the boost::process::std_out > "myfifo" line doesn't return because it's waiting on the open call to return, which it doesn't because "myfifo" is a fifo. Is this a bug?

#include <boost/process.hpp>

int main(int, char**)
{
    mkfifo("myfifo", 0600);
    auto x = boost::process::std_out > "myfifo";
    return 0;
}
Mike
  • 693
  • 3
  • 13
  • What are you hoping the "auto x = boost::process::std_out > "myfifo";" line will do? with a single > that's a comparison but I doubt those two arguments are comparable. Did you mean >>? – SoronelHaetir Dec 14 '17 at 22:02
  • 1
    boost::process overloads `operator>` to setup redirections from process invocations. I'd like to use it in a `boost::process::child::child` call to start a process, but it hangs here before I can even call that. – Mike Dec 14 '17 at 22:05
  • 1
    @SoronelHaetir It's a little ironic that you posted that comment, clearly without even looking at the docs or having used Boost Process before :) – sehe Dec 14 '17 at 22:31

1 Answers1

0

That's interesting, because the behaviour of the code you use is undefined.

First Off

The parameter keywords are, effectively, a "DSL" that builds extension properties to be used by the executor.

In spite of the fact that the implementation details of the template expressions is unspecified, one would expect lone parameter objects to have no observable side effects.

That makes your observed hang remarkable. I think it's a weak design when the mere composition of the argument expressions has side-effects (even on destruction, by the way). It would be much better if the actions would only run at the time of process execution, IMHO.

You might report this to the library developers (though they'll probably say "don't do that" and mark it as "by design").

Second, Your Expectation Is Wrong

In fact bp::std_out > "filename", does not try to open the fifo. It tries to create the file (since it's write-only, and you intend to write data to it).

If you want to write to a fifo, you will want to use the pipe or async_pipe facilities.

sehe
  • 374,641
  • 47
  • 450
  • 633
  • First off, it's not a Template DSL executed by other code. Trust me, I've pored over the code. I thought that at first as well. But no, the actual open call is made in the code I wrote. It perfectly reasonable to do it this way. No need to make a DSL. Second, this isn't real-world code. It's the smallest bit of code that exemplifies the issue, which is why it doesn't include all the other code that leads up to it. – Mike Dec 15 '17 at 16:55
  • Did you miss 80% of my answer? I didn't just comment "you're doing it wrong" at the question, did I? I understood that, it just was unclear whether you were aware of things. After all, you don't mention it, and there are other things you were not aware of (which I mention in my answer). I'm sorry if sometimes we need to assume things that aren't explicit in the question. – sehe Dec 15 '17 at 17:06
  • Re.: "Believe me". [Erm](https://stackoverflow.com/questions/47630796/function-with-variable-parameter-size-how-to-conditionally-set-some-arguments/47634444#47634444). I've written bug fixes, and developed new custom extensions. [Anyways, I've pointed out the exact same things you explain, in my answer. I happen to hold the opinion that it's a design weakness. I'm happy to disagree with anyone on that.] – sehe Dec 15 '17 at 17:06
  • I wasn't trying to be an ass, though I guess one might take that from my comment. Anyway, I'm not able to use the `pipe(const std::string& name)` constructor because it unlinks the fifo after it opens it which I imagine makes sense in some situations, but not mine because I'm trying to read from the fifo outside of a `boost::process` started process. Any other ideas? – Mike Dec 15 '17 at 17:21
  • 1
    Yeah, I'd file a feature request, and for now setup an async read loop (the only thing that actually reliably works, anyways IIRC) that copies from the fifo into an `async_pipe`. Let me think whether I did something like this once. But it will have to be later. – sehe Dec 15 '17 at 17:41