Re: [boost] [process] Formal Review starts today, 27 October

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:
> <snip>
>
>> 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.
>
> John
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 
boost::filesystem:

if (fs::exists(my_path))
     fs::istream is(my_path);

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.