Subject: Re: [boost] [process] Formal Review starts today, 27 October
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-10-30 12:03:53
Am 30.10.2016 um 16:48 schrieb John Bytheway:
> On 2016-10-28 09:04, Klemens Morgenstern wrote:
>> It's not working at all with path, it depends on the OS. The cmd-style
>> searches path, while he exe-args style does not. That's the weird
>> platform dependent behaviour, I'm not elaborating on enough.
>> Boost.Process does not search the path automatically, it just uses the
>> defaults of the OS. If you want to search the path, you have the
>> search_path function for that, i.e. turn the first line into
>> boost::filesystem::path p = bp::search_path("python.exe");
> So you are suggesting searching the path for the executable and then
> running it as a separate step? That sounds like it would introduce a
> race condition (if the executable is moved between being found and run)
> which could cause execution to fail where it would otherwise succeed
> (assuming there is another program with the same name later on the path).
> That makes me uncomfortable. At the least, that warrants a warning in
> the docs, and I feel it ought to not be the recommended approach.
> But maybe I'm misunderstanding; I haven't actually looked at your docs yet.
You mean it's a race condition, because the OS would block moving of the
file before launching?
I guess that could happen, but that's true for all such operations, e.g.
if during launch of foo.exe you move it's needed bar.dll. Or if you use
So yes if you write bp::system(bp::search_path("foo.exe")); you'd have a
few cycles in between to move the file.
However, I don't think that's the problem: you either have a command
line, in which case the OS takes care of that or you have an absolute
path. The search_path function helps you to obtain the latter, but does
not lock it. I guess you could open a handle to the file to do that, but
that would be very strange default behaviour.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk